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Preface 


The  purpose  of  this  thesis  is  to  develop  an  abstract  data  model  of  a  computer  aided  soft- 
ware  engineering  (CASE)  methodology,  and  to  compare  the  query  complexity,  database  size,  and 
-peed  of  query  execution  of  a  relational  database  management  system  (DBMS)  implementation  of 
the  methodology  with  a  nested-relational  DBMS  implementation.  The  United  States  Air  Force 
Integrated  Computer  Aided  Manufacturing  (ICAM)  program  defines  a  subset  of  Ross's  Structured 
Analysis  (SA)  language  called  ICAM  Definition  Method  Zero  (IDEFo);  it  is  precisely  this  IDEFo 
-ubset  that  is  considered  (30)(25).  Ingres  Corporation's  relational  DBMS,  Ingres,  is  the  implemen¬ 
tation  media  for  the  relational  version;  the  University  of  Wisconsin's  Extensible  Object-oriented 
Database,  Exodus,  is  the  implementation  media  for  the  nested-relational  version  ( 2 9 ) ( T ) . 

The  comparison  is  undertaken  to  demonstrate  potential  advantages  of  a  nested-relational 
DBMS  for  this  application.  Additionally,  the  development  of  an  abstract  data  model  for  IDEFo  Is 
directly  related  to  on-going  AFIT  research  efforts  associated  with  the  Strategic  Defense  Initiative 
Organization  (SDIO),  which  has  adopted  the  IDEFo  analysis  language. 

I  extend  my  gratitude  to  several  people  who  supported  me  during  this  effort.  I  thank  my 
thesis  advisor.  Major  Mark  Roth  for  his  patience  and  guidance  in  the  area  of  database  theory  and 
application.  I  thank  the  other  two  members  of  my  committee.  Dr.  Thomas  Hartrum,  who  strongly 
influenced  the  development  of  the  abstract  data  model,  and  Dr.  Gary  Lamont,  who  taught  me 
early  on  to  assume  nothing  and  to  return  to  first  principles  when  lost.  I  thank  Capt  Neal  Smith 
and  Capt  Ken  Austin,  who  helped  me  develop  the  abstract  data  model.  I  thank  Capt  Mike  Mankus 
who  developed  the  nested-relational  DBMS  and  Capt  Jim  Kirkpatrick  for  his  insight  in  helping  me 
develop  the  nested-relational  version.  I  especially  thank  Penny  for  her  moral  support  during  these 
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Abstract 

A  This  thesis  develops  an  abstract  data  model  of  a  particular  computer  aided  software  engineer¬ 
ing  (CASE)  methodology,  and  compares  the  query  complexity,  database  size,  and  speed  of  query 
execution  of  a  relational  database  management  system  (DBMS)  implementation  of  the  methodology 
with  a  nested-relational  DBMS  implementation  of  the  same  CASE  methodology.  In  particular,  the 
thesis  considers  the  Enited  States  Air  Force  Integrated  Computer  Aided  Manufacturing  (ICA.M) 
program's  subset  of  Ross's  Structured  Analysis  (SA)  language  called  ICAM  Definition  Method  Zero 
ilDEFrA-  Ingres  Corporation's  relational  DBMS.  Ingres,  is  the  implementation  media  for  the  rela¬ 
tional  version.  The  Fniversity  of  Wisconsin's  extensible  database,  Exodus,  is  the  implementation 
media  for  the  nested-relational  version.  , 

'l'he  thesis  provides  background  information  on  the  development  of  CASE  methodologies  and 

th'-  development,  of  database  management  systems.  Additionally,  it  provides  an  overview  of  the 

IDFF  :  analysis  language,  and  the  Exodus  extensible  DBMS.  '  p 

f 

Included  in  the  thesis  is  an  abstract  data  model  of  the  IDEFo  language.  The  model  partitions 
[|)FF  into  an  essential  data  model  and  a  drawing  data  model.  This  partitioned  representation 
facilitates  ongoing  and  future  research  relative  to  syntax  checking,  generation  of  an  executable 
software  specification,  and  automatic  layout  of  SA  diagrams.  Since  IDEFo  is  the  analysis  method¬ 
ology  selected  by  the  Strategic  Defense  Initiative  Organization,  the  abstract  data  model  alone  is  of 
importance. 

The  abstract  data  model  is  mapped  into  a  relational  representation  and  implemented  within 
I n gp .  l  ie'  relational  representation  is  mapped  into  a  nested-relational  representation  and  imple- 
iii-  hi -%d  within  Exodus.  The  two  implementations  are  compared  to  see  if  there  are  any  advantages 
p.  I--  gained  bv  using  a  nested-relational  DBMS  for  this  type  of  application  (CASE  tool  data).  Die 
ip  is  ,  ,|  ,  oiiipari'i  n  1 1 1 1 1 1  - 1<  -  querv  complexity.  s|/e  of  the  database,  and  speed  ot  query  execution 
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A  COMPARISON  OF  A  RELATIONAL 


AND  NESTED-RELATIONAL  IDEF0 
DATA  MODEL 


I.  IXTR OD UCTION 


(lateral  Issues 

The  application  of  the  modern  digital  computer  was  the  stepping-stone  from  which  soft¬ 
ware  engineering  and  database  theory  developed.  This  thesis  investigation  involves  both  software 
•  ngineering  and  database  management  systems  (DBMS)  It  compares  a  relational  DBMS  imple¬ 
mentation  of  a  software  engineering  methodology  with  a  nested-relational  DBMS  implementation 
of  the  same  methodology.  The  United  States  Air  Force  Integrated  Computer  Aided  Manufactur¬ 
ing  ((CAM)  program  defines  a  subset  of  Ross’s  Structured  Analysis  (SA)  language  called  ICAM 
Definition  Method  Zero  (IDEF0j;  it  is  this  language  which  is  considered  in  this  research  (25)  (30). 
I'he  relational  version  of  the  IDEFo  language  is  implemented  within  Ingres  Corporation's  rela¬ 
tional  DBMS.  Ingres  (29).  The  nested-relational  version  is  implemented  within  the  University  of 
Wisconsin's  Extensible  Object-oriented  Database,  Exodus  (4). 

The  comparison  is  undertaken  to  determine  potential  advantages  relative  to  query  complexity, 
<ize  of  the  database,  and  speed  of  query  execution  of  a  nest^-relational  DBMS  for  the  application 
of  computer  aided  software  engineering  (CASE)  tools.  Additionally,  the  development  of  an  abstract 
data  model  for  the  IDEFo  language  is  directly  related  to  oil-going  AFIT  research  efforts  associated 
with  the  Strategic  Defense  Initiative  Organization  (SDIO),  which  has  adopted  the  IDEFo  analysis 
Language. 
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Back- ground 


Overview  of  CASE  Development.  Software  engineering  is  a  relatively  new  field  which  has 
undergone  dramatic  transformation  in  the  past  40  years.  In  the  early  years,  computer  programming 
and  software  development  in  general  was  pretty  much  a  "black  art"  which  depended  upon  the  skill 
of  a  few  "high  priests."  There  were  often  cost  and  schedule  overruns.  As  Betty  Forman  said.  "If 
carpenters  built  buildings  the  way  programmers  write  programs,  the  first  termite  would  destroy 
civilization"  (13:53).  The  community  recognized  this  problem  and  began  to  address  it.  A  workshop 
m  lOiiS.  in  Garmisch.  West  Germany,  and  a  subsequent  one  in  Rome.  Italy  in  19(39  looked  at  the 
growing  technical  and  managerial  problems  associated  with  the  development  and  maintenance  of 
computer  software.  According  to  Fairley,  it  was  these  workshops  which  coined  the  phrase,  software 
engineering  ( 12:4).  Fairley  proposes  the  following  definition  for  software  engineering: 

Software  engineering  is  the  technological  and  managerial  discipline  concerned  with  sys¬ 
tematic  production  and  maintenance  of  software  products  that  are  developed  and  mod¬ 
ified  on  time  and  within  cost  estimates.  (12:4) 

There  are  literally  dozens  of  software  engineering  approaches  covering  virtually  all  phases 
of  software  development.  Some  the  theoretical  work  concentrated  on  the  requirements  analysis 
phase.  Larry  Constantine  invented  data  flow  diagrams  and  perhaps  structured  programming:  one 
of  the  first  books  on  structured  design  was  written  by  Constantine  and  Edward  Yourdon  (41).  Tom 
DeMarco  wrote  the  classic  book  on  the  principles  of  structured  analysis  and  showed  the  use  of  data 
How  diagramming  as  part  of  a  software  analysis  methodology  (11).  Paul  Ward  and  Steve  Mellor 
did  important  work  in  the  area  of  real-time  structured  analysis;  Ward's  1985  paper  describes  the 
extensions  made  to  DeMarco's  data  flow  diagram,  which  allow  it  to  represent,  timing  and  control 
information  (40).  In  1987,  Paul  Ward,  Hughes  Aircraft  Company's  Randall  Jensen.  Honeywell's 
William  Bruyn,  and  Boeing's  Dinesh  Keskar,  developed  the  Extended  System  Modeling  Language 
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(ESML),1  a  method  that  combines  some  features  of  both  the  Hatley  and  VVard-Mellor  methods 
(IS). 

Rog^r  Pressman  gives  an  overview  of  some  other  approaches  (27).  For  example,  Jackson 
System  Development  (JSD)  combines  a  natural  language  during  the  initial  phases  with  structure 
charts  and  structured  text  added  during  the  later  phases.  Another  methodology  is  the  VVarnier- 
Orr  Data  Structured  Systems  Development  (DSDD).  which  considers  data  hierarchy,  information 
flow,  and  functional  characteristics.  There  are  several  methodologies  based  upon  some  type  of 
requirements  language,  e  g.,  Software  Requirements  Engineering  Methodology  (SRE\1),  and  Prob¬ 
lem  Statement  Language/Problem  Statement  Analyzer  (PSL/PSA).  Another  increasingly  popular 
approach  is  the  so-called  object-oriented  methodology,  which  attempts  to  link  real-world  objects 
and  their  associated  operations. 

Of  particular  interest,  is  Ross’s  Structured  Analysis  (30).  This  graphical  analysis  language  is 
the  basis  for  IDEFo,  the  language  modeled  in  this  investigation  (25).  Like  the  traditional  data  flow 
diagram,  SA  is  a  hierarchical  decomposition.  It  allows  data  (nouns)  and  activities  (verbs)  to  be 
modeled  via  arrows,  boxes,  and  other  graphical  and  textual  devices.  Additional  information  about 
SA  and  IDEFo  is  given  in  Chapter  II  of  this  thesis. 

The  early  t  heoretical  work  naturally  led  to  the  development  of  computer  based  tools  to  assist 
t !)<-*  software  developers  The  term  computer  aided  software  engineering  (CASE)  is  used  to  describe 
these  computer  based  tools.  First-generation  CASE  tools  were  developed  using  a  theoretical  and 
technological  base  that  changed  even  as  the  tools  were  being  written.  To  a  large  extent  this  is  still 
true.  Many  of  today’s  CASE  products  are  constantly  being  revised  to  accommodate  new  theories, 
methodologies,  and  programming  languages.  CASE  has  become  a  grab  bag  for  a  variety  of  software 
products  and  services;  some  are  quite  valuable,  other  are  just  "pieces  of  methodology  out  chasing 
markets"  (17.52).  A  list  of  some  commercially  available  CASE  tools  is  included  in  Appendix  A. 

'While  assigned  to  the  Government  Plant  Representative  Office  at  Hughes,  I  had  the  opportunity  to  review  Dr 
Jensen's  draft  paper  on  the  ESML  model. 
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A  software  development  organization  needs  a  suite  of  CASE  tools  rather  than  one  "super- 
tool."  In  fact  any  one  tool  that  tried  to  combine  all  features  would  be  rather  unwieldy.  Hawley 
expresses  this  sentiment  rather  succinctly: 

To  combine  all  the  functions  and  features  known  to  CASE  tools  and  designate  that  list 
as  the  standard  is  a  disservice  to  users  and  vendors.  It  makes  the  ideal  CASE  product 
resemble  an  elephant;  enormous,  clumsy,  frightened,  and  expensive.  (17:53) 

Since  each  of  the  tools  within  a  CASE  environment  must  be  able  to  use  the  data  generated 
by  the  other  tools,  it  is  important  to  develop  a  formal  or  semi-formal  model  for  each  methodology 
being  automated  and  create  an  environment  in  which  each  of  these  models  can  exchange  data, 
perhaps  through  some  type  of  DBMS. 

Overview  of  Database  Development.  Database  system  theory  is  even  more  fledgling  than 
computers  and  software  in  general.  In  the  thirty  years  since  1960,  it  has  experienced  dramatic 
changes.  Businesses  took  advantage  of  the  power  and  speed  of  computers;  the  complexity  and  size 
of  data  processing  applications  began  to  grow.  These  applications  were  based  on  a  file-processing 
system  wherein  the  various  pieces  of  information  were  stored  in  separate  files.  Korth  and  Silber- 
schatz  point  out  that  this  file-based  approach  has  major  disadvantages  such  as  data  redundancy, 
difficulty  in  accessing  data,  concurrency  problems  due  to  multiple  users,  and  security  problems 
("J0:"2)  Companies  such  as  IBM,  North  American  Aviation  (now  Rockwell  International),  and 
General  Electric  had  extensive  database  requirements  that  were  rapidly  exceeding  the  capability 
of  the  existing  programmer  community.  It  was  becoming  difficult  for  these  large  organizations  to 
complete  existing  projects,  let  alone  take  on  new  projects.  Increasing  amounts  of  time  were  being 
-pent  on  special  purpose  code  to  accommodate  multiple  users,  provide  adequate  security,  ensure 
the  integrity  of  data,  and  so  forth.  Each  new  application  basically  reinvented  the  wheel  in  terms  of 
data  structures,  access  methods,  and  so  forth.  As  a  consequence  of  these  issues,  database  manage¬ 
ment  systems  (DBMS)  were  developed.  As  far  as  traditional  business  applications  are  concerned, 
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database  system  tlieorv  and  practice  appears  to  have  matured  and  stabilized.  "The  fundamental 
database  system  concepts  are  now  well  defined  and  well  understood"  (20:xiii). 

The  first  DBMS  systems  were  based  upon  the  hierarchical  model.  In  this  logical  approach, 
records  are  contained  in  multiple  levels  that  graphically  form  a  tree  structure  with  the  root  at  the 
top  and  the  branches  formed  below.  There  is  a  distinct  superior-subordinate  relationship  Figure  1 
is  an  example  of  a  hierarchical  database  structure  based  upon  Date’s  supplier,  parts,  and  shipments 
database  (10:64).  The  data  base  is  a  forest  of  trees,  each  of  which  has  a  root  node  record  Below 
the  root  record  are  subordinate  record  nodes,  each  of  which,  in  turn,  owns  one  or  more  other 
nodes  (perhaps  none).  Each  node  in  the  tree,  except  the  root,  has  a  single  owner.  Each  of  the 
records  in  the  tree  contains  a  collection  of  fields.  Each  field  contains  a  single  value.  Because  of  the 
structure,  data  must  often  be  replicated  in  several  different  locations  within  a  hierarchical  database. 
According  to  Korth  and  Silberschatz,  this  presents  two  major  drawbacks:  (1)  data  inconsistency 
may  result  when  updating  takes  place,  and  (2)  waste  of  space  is  unavoidable  (20:144). 


Figure  1.  Typical  Hierarchical  Database 

As  database  theory  continued  to  develop,  some  of  the  problems  inherent  in  the  hierarchical 
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model  were  circumvented  by  the  more  sophisticated  network  model.  Like  the  hierarchical  model, 
a  network  database  consists  of  a  collection  of  records  connected  via  links.  Unlike  the  hierarchical 
model,  the  network  model  allows  arbitrary  graphs  as  opposed  to  trees.  Thus,  each  node  may  have 
several  owners  and  may,  in  turn,  own  any  number  of  other  records.  The  network  model  provides  a 
mechanism  by  which  a  field  can  have  a  set.  of  values.  It  also  reduces  the  amount  of  replicated  data 
inherent  in  the  hierarchical  model.  Figure  2,  which  is  borrowed  substantially  from  Date,  shows  a 
typical  network  database  (10:64). 


The  Database  Task  Group  (DBTG)  of  the  Conference  on  Data  Systems  Languages  group 
(CODASYL),  which  had  set  the  standard  for  the  COBOL  language,  studied  a  number  of  these 
network-based  DBMS  in  the  late  1960s.  This  study  resulted  in  the  first  database  standard  specifi¬ 
cation.  the  so-called  DBTG  network  model. 

Research  on  database  systems  continued.  E.  F  Codd,  at  the  IBM  Research  Laboratory  in 
*vin  .lose,  introduced  the  relational  model  in  his  1970  paper  (7).  A  relational  database  consists  of 
a  collection  of  tables  (relations),  each  having  a  unique  name.  Each  table  has  a  number  of  columns 
(attributes),  which  also  have  a  unique  name.  The  primary  assumption  of  Codd’s  relational  model  is 


that  all  attributes  in  a  relation  can  only  have  atomic  values,  i.e.,  cannot  be  decomposed.  A  relation 
which  only  has  atomic  valued  attributes  is  said  to  be  in  first  normal  form  (INF).  Codd’s  paper 
includes  a  rigorous  mathematical  treatment  of  the  subject.  Additionally,  his  model  provides  the 
mechanism  for  separating  the  programs  from  the  machine  representation  and  organization  of  data 
(one  of  the  big  problems  associated  with  both  the  hierarchical  and  network  database  models)  A  set 
of  relations  from  Date's  sample  database,  is  shown  in  Figure  3  (10:64).  According  to  Stonebraker. 
(.odd's  paper  "started  a  heated  controversy  in  all  ACM  SIGF1DET  (now  SIGMOD)  meetings  from 
1971  onward  between  two  collections  of  people...”  (3(5:1).  The  previously  mentioned  CODASYL 
group  was  pushing  the  DBTG  network  model  (their  recently  defined  database  standard),  while 
(  'odd  and  academic  researchers  were  pushing  the  relational  model 
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Figure  3.  Typical  Relational  Database 


Two  influential  prototype  database  systems  based  on  the  relational  model  were  developed  and 
subsequently  commercialized.  These  two  systems,  "helped  shape  a  fair  amount  of  the  history  that 
followed”  (36.2).  The  IBM  Research  Laboratory  at  San  Jose  built  System  R,  and  the  University 
of  California  at  Berkeley  built  Ingres.  Ingres  was  eventually  commercialized  by  several  companies, 
including  Relational  Technology  (now  Ingres  Corporation).  System  R  was  also  commercialized  by 
several  companies  including  Oracle. 

By  and  large,  the  relational  model  is  the  de  facto  database  standard.  However,  research  in 
t lie  database  arena  has  continued,  and  several  other  models  have  been  proposed.  One  such  model, 
which  has  found  significant  use  during  the  design  phase  of  databases,  is  Chen's  entity-relationship 
model  (6)  Basically  the  E-R  model  extends  the  relational  model  with  the  concepts  of  entities, 
which  are  represented  by  rectangles;  attributes,  which  are  represented  by  ellipses;  relationships, 
which  are  represented  by  diamonds;  and  the  links  between  them,  which  are  represented  by  lines 
An  example  E-R  diagram  based  upon  Date’s  database  is  shown  in  Figure  4.  There  do  not  seem  to 
be  any  commercial  database  systems  that  use  the  entity-relationship  model  as  their  underlying  data 
model.  Nonetheless,  the  E-R  model  has  obvious  uses,  in  particular  for  logical  database  design2. 
In  fact,  many  commercial  relational  database  design  tools  require  the  database  administrator  to 
express  data  using  the  E-R  model.  Stonebraker  explains  why  the  E-R  model  never  really  took 
hold.  "The  relational  model  was  dramatically  and  obviously  better  than  the  older  hierarchical  and 
network  models.  The  E-R  model,  on  the  other  hand  was  not  seen  to  be  dramatically  better  than 
the  relational  model"  (36:369). 

Stonebraker  gives  an  overview  of  some  other  database  approaches,  for  example;  the  functional 
model  attempts  to  view  the  database  as  a  collection  of  functions,  the  semantic  data  model  is 
an  attempt  to  deal  with  what  Stonebraker  calls  the  “semantic  poverty"  of  the  relational  model 
(36).  Another  increasingly  popular  approach  is  the  so  called,  object-oriented  approach3.  The 

-The  IDEFo  Tata  model  in  this  thesis  is  derived  via  an  entity-relationship  analysis. 

!The  Exodus  DBMS  used  to  implement  the  nested- relational  IDEFo  database  is  an  object  oriented  system. 
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Figure  4.  Typical  Entity-Relationship  Diagram 

exact  meaning  of  object-oriented  varies  from  person  to  person.  Bancilhon  describes  the  main 
characteristics  of  an  ohject-oriented  system  which  should,  in  turn,  be  manifested  in  any  DBMS  that 
chooses  to  be  called  object-oriented.  These  characteristics  include  encapsulation,  object  identity, 
types  and  classes,  inheritance,  overriding  and  late  binding,  and  degrees  of  freedom  (2:152). 

Another  important  database  model  is  the  nested-relational  model,  which  is  basically  an  ex¬ 
tension  of  Codd’s  relational  model.  The  extension  allows  for  attributes  within  a  relation  to  be 
multi-valued  or  even  relation-valued,  i.e.,  the  INF  assumption  is  relaxed.  Perhaps  the  earliest 
work  in  this  area  was  done  by  Makinouchi,  who  considered  set  valued  attributes  (22).  Thomas 
and  Fischer  subsequently  extended  this  concept  to  include  relation-valued  attributes  (38).  Roth. 
North.  and  Batory  proposed  extensions  t.o  the  SQL  query  language  (SQL/NF)  so  that  it  could 
deal  with  these  non-first  normal  form  (->1NF)  relations  (33).  The  nested  model,  while  retaining 
Codd's  traditional  operators,  also  has  two  new  operators,  nest,  and  unnest.  These  operators  are 
be>t  explained  by  way  of  the  following  example  from  Maukus: 


suppose  a  relation  r  is  defined  on  some  scheme  R,  with  attributes  A.  B,  and  C .  This 
may  be  denoted  as  R  =  (ABC)-  If  the  attributes  B  and  C  are  then  nested  under  one 
attribute,  thus  giving  us  a  relation-valued  attribute,  the  scheme  may  now  be  shown  as 
R'  =  (AD),  D  =  ( BC ),  where  B  and  C  are  nested  under  the  D  attribute  of  R' .  By 
unnesting  R'  with  the  unnest  operator,  the  scheme  R  =  (ABC)  is  returned.  (23) 
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One  advantage  of  the  nested  model  is  that  it  can  deal  with  complex,  hierarchically  structured 
objects  wherein  an  object  is  composed  of  lower  level  subobjects.  A  good  example  of  this  is  seen  in  a 
personal  computer  The  object  "computer"  is  made  up  of  subobjects  such  as  "monitor”,  and  "disk 
drive.”  Each  of  these  subobjects,  in  turn  may  be  comprised  of  subobjects.  For  example,  "moni¬ 
tor"  is  comprised  of  subobjects  such  as  "circuit  board,"  which,  in  turn,  is  made  from  "integrated 
circuits,"  "resistors,”  "capacitors,"  etc.  Each  subobject  is  dependent  upon  its  parent  object.  If 
the  parent,  is  deleted,  so  are  all  its  subobjects.  Although  there  do  not  seem  to  be  any  commercial 
databases  based  upon  the  nested  relational  model,  there  are  prototype  research  systems  such  as 
that  built  by  Mankus  (23), 

The  current  situation  is  that  relational  database  systems  work  quite  well  for  business  data- 
ptocessing  applications.  However,  if  you  "stray  from  data  that  looks  like  the  SUPPLIER-PARTS- 
Sl'PPLY  example  popularized  by  Codd  or  the  EMP-DEPT  examples  also  in  widespread  use,  rela¬ 
tional  systems  tend  to  run  into  trouble  very  quickly"  (36:477).  In  nonbusiness  application  areas  the 
opportunity  to  stray  is  rampant.  For  example;  CAD  applications  need  to  store  two-dimensional  and 
three-dimensional  objects  in  some  type  of  database;  considerable  research  has  been  expended  on 
trying  to  integrate  database  management  systems  with  artificial  intelligence  systems;  Rubenst-un 
describes  the  design  of  a  database  system  for  musical  information  (34).  It  is  almost  certain  that 
next-generation  CASE  tools  will  put  software  specifications,  definition  of  forms,  reports,  graphs, 
and  even  source  code  in  a  database.  In  all  these  areas,  current  relational  systems  tend  to  work 
poorly;  user  queries  are  difficult  to  construct  and  they  execute  slowly.  As  a  result,  developers  of 
these  kinds  of  applications  generally  ignore  relational  technology.  Some  other  database  approach 
might  prove  useful.  Particularly  in  a  data  intensive  area  such  as  CASE  tools. 

Problem  Statement 

The  purpose  of  this  thesis  investigation  is  to  analyze  the  data  requirements  of  the  IDEFq 
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structured  analysis  language;  develop  an  abstract  data  model  of  the  language;  implement  this  data 
model  within  an  Ingres-based  relational  DBMS;  implement  the  model  within  an  Exodus-based 
nested-relational  DBMS;  compare  the  two  implementations  in  terms  of  query  complexity,  size  of 
the  database,  and  speed  of  query  execution;  and,  based  upon  the  comparison,  determine  if  the 
nested-relational  implementation  of  the  model  is  more  appropriate  for  the  IDEF0  application. 

Finn  of  Attack 

The  plan  of  attack  is  to  analyze  the  data  requirements  of  the  IDEFo  language  and  develop 
an  abstract  data  model.  After  the  data  model  is  complete,  it  is  mapped  to  a  set  of  relations  and 
implemented  in  the  Ingres  relational  DBMS.  An  example  database  instance,  and  a  series  of  queries 
is  developed  to  extract  data  from  the  relational  implementation.  The  relational  model  is  then 
mapped  into  a  nested-relational  representation  and  implemented  within  the  Exodus-based  nested- 
relational  DBMS.  An  example  database  instance  containing  the  same  information  as  the  relational 
instance  is  developed,  as  well  as  a  series  of  queries  to  extract  data  from  the  nested-relational  version. 
Finally,  comparisons  between  the  two  implementations. are  generated.  These  comparisons  include 
complexity  of  queries,  speed  of  query  execution,  and  size  of  the  database. 

Development  of  an  Abstract  Data  Model.  In  order  to  facilitate  development  of  the  relational 
and  nested-relational  DBMS  implementation  of  the  IDEFo  language,  an  abstract  data  model  of  the 
language  is  constructed.  This  abstract  data  model  consists  of  two  parts,  the  essential  data  model, 
and  the  drawing  data  model.  The  former  captures  only  the  essence  of  the  analysis  language  in  terms 
of  act  ivities  and  data  elements,  whereas  the  latter  captures  only  those  portions  of  IDEFo  which  are 
strictly  graphical  constructs.  This  approach  allows  future  tools  to  extract  analysis  data  without 
having  to  deal  with  the  fact  that  the  analysis  language  was  IDEFo.  The  concept  is  illustrated  in 
Figure  5. 
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Figure  5.  IDEFo  Abstract  Data  Model 


Essential  Data  Model.  The  IDEFo  essential  data  model  captures  those  portions  of  the 
language  which  represent  the  semantics  (relative  to  a  human  interpretation)  of  a  particular  analysis. 
This  includes,  for  example,  activities  and  their  children,  as  well  as  data  elements.  It  does  not 
include,  for  example,  the  location  of  the  boxes  or  arrows  which  graphically  represent  the  activities 
and  data  elements.  As  mentioned  earlier,  this  approach  allows  future  tools  to  extract  analysis 
information  without  having  to  deal  with  the  IDEFo  graphical  representation  explicitly,  i.e.,  without 
having  to  "walk  through”  the  drawing. 

The  entity-relationship  model  is  used  to  analyze  the  essential  data  model  since  it  allows  for 
•*asy  mapping  into  a  relational  design.  Furthermore,  one  of  the  advantages  of  the  entity-relationship 
approach,  as  explained  earlier,  is  that  it  retains  many  of  the  semantics  of  the  actual  data  being 
modeled. 


Drawing  Data  Model.  The  drawing  data  model  represents  the  actual  graphical  con- 
'tnicts.  e  g.,  boxes,  arrows,  etc.,  used  to  represent  the  particular  IDEFo  analysis.  This  data  is  used 
to  draw  an  IDEFo  model.  It  contains  such  information  as  the  location  of  boxes,  the  line  segments 
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which  graphically  represent  a  given  data  element,  etc.  For  the  same  reasons  as  before,  an  E-R 
analysis  is  used  to  derive  the  model. 

Mapping  of  Abstract  Data  Model  The  mapping  of  an  E-R  model  into  the  corresponding 
relations  is  relatively  straight  forward.  An  example  of  a  mapping  approach  is  given  in  Chapter 
2  of  Korth  and  Silberschatz  (20:21).  After  the  mapping  into  relations  is  accomplished  and  tuned 
via  stepwise  refinement,  it  is  a  simple  task  to  implement  the  design  within  the  Ingres  DBMS.  The 
mapping  into  a  nested-relational  model  is  a  different  matter.  There  are  paradigms  for  mapping 
a  scheme  into  a  nested-relational  design  given  a  universal  relation,  its  functional  dependencies, 
and  multivalued  dependencies  (31).  Unfortunately,  there  is  no  easy  way  to  determine  multivalued 
dependencies,  particularly  if  the  data  model  is  developed  using  classical  methods  such  as  E-R 
Thus,  the  development  of  the  nested-relational  design  is  essentially  still  an  art  form  which  relies  on 
the  skill  of  the  analyst.  Following  the  nested-relational  mapping  is  the  implementation  within  the 
Exodus  DBMS. 

Example  Database  Instance.  A  two-level  IDEFo  analysis  is  used  as  the  basis  for  the  example 
database  instances  This  instance  is  loaded  into  the  relational  implementation,  and  the  nested 
relational  implementation  Identical  instances  in  each  version  allow  for  a  somewhat  normalized 
comparison. 

Development  of  Queries.  Typical  queries  to  extract  data  from  the  example  database  are 
developed.  For  the  relational  version,  the  query  language  is  SQL.  Queries  to  extract  the  identical 
data  from  the  nested-relational  implementation  are  developed.  Although  the  query  language  for 
Mankus's  nested-relational  DBMS  is  based  upon  Colby  algebra,  the  ultimate  goal  is  to  build  a 
query  language  front  end  based  upon  Roth's  SQL/NF  (8)  (33).  Accordingly,  the  nested-relational 
queries  are  written  in  SQL/NF  and  translated  into  Colby  algebra.  The  justification  for  writing  the 
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queries  in  SQL/N'F  pertains  to  the  query  complexity  comparisons  between  the  nested-relational 
version  and  relational  version. 

Comparison.  The  comparison  is  a  somewhat  difficult  issue.  One  area  that  could  provide 
useful  data  is  in  the  area  of  query  complexity.  In  order  to  determine  which  query  is  "more'' 
complex,  complexity  is  quantified  in  terms  of  query  language  constructs.  The  queries  associated 
with  the  relational  and  nested-relational  implementations  are  compared  based  on  these  complexity 
measures. 

I  he  comparison  of  the  size  of  the  database  files  seems  to  be  rather  straight  forward.  Unfor¬ 
tunately.  a  simple  comparison  of  file  size  is  not  necessarily  meaningful.  Is  the  smaller  size  due  to  an 
intrinsic  property  of  the  data  model  or  is  it  due  to  the  skill  of  the  database  programmer  in  choos¬ 
ing  a  data  structure?  The  best  that  can  be  done  with  this  approach  is  to  build  several  database 
instances  and  attempt  to  draw  some  qualified  concluc;''"«.  On  the  other  hand,  if  a  relational  exam¬ 
ple  database  instance  and  a  nested-rela'i  uiat  example  database  instance  (containing  the  identical 
data)  are  compared  byte  by  byte,  on  paper,  then  the  logical  size  of  each  can  be  determined.  This 
provides  a  worst  case  comparison,  since  internal  representations  tend  to  compress  data. 

While  it  is  rather  easy  to  simply  compare  the  running  time  of  the  two  implementations  for 
various  queries,  the  numbers  are  again  not  necessarily  meaningful.  Is  the  faster  running  time  of 
one  model  due  to  an  intrinsic  property  of  the  model  or  is  it  due  to  a  more  skillful  programming 
effort'.’  Does  the  Ingres  version  run  faster  because  there  a  fewer  people  logged  in?  Does  Exodus 
run  faster  because  it  is  on  a  Sun  workstation'7  The  best  that  can  be  done  with  such  an  approach  is 
to  examine  a  number  of  different  queries  and  attempt  to  draw  some  qualified  conclusions.  A  more 
reasonable  approach  is  to  consider  query  speed  in  terms  of  number  «  '  disk  accesses  (assuming  a 
disk  based  DBMS  approach),  or  an  order-of  analysis  on  programs  which  run  the  embedded  query 
language  queries  (assuming  a  memory  based  DBMS).  This  latter  approach  obviously  depends  upon 
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the  size  of  a  given  IDEFo  analysis.  It  may  not  be  possible  to  load  the  complete  set  of  data  for  a 
given  project  into  memory  at  one  time. 

>Y ope  and  Limitations 

Scope.  The  thesis  effort  covers  four  specific  areas  as  indicated  below: 

1  Development  of  an  abstract  data  model  for  the  IDEFo  language. 

2.  Design  and  implementation  of  an  Ingres-based  relational  database  to  capture  the  IDEFo  data. 

3.  Design  and  implementation  of  an  Exodus-based  nested-relational  database  to  capture  the 
IDEFo  data 

1  Comparison  of  the  two  DBMS  implementations  to  determine  the  benefits,  if  any,  associated 
with  the  use  of  a  nested-relational  DBMS  for  such  applications. 

L umfafions.  The  development  of  the  abstract  data  model,  and  the  nested-relational  imple¬ 
mentation  of  this  model  are  the  primary  areas  of  emphasis.  The  ability  to  use  the  abstract  data 
model  in  other  on-going  thesis  efforts  relative  to  IDEFo  is  of  primary  concern.  In  particular. 
Smith's  Ada  implementation  of  SAtool  uses  the  data  model,  as  does  Austin’s  implementation  of  a 
Structured  Analysis  Tool  Interface  to  the  Strategic  Defense  Initiative  Architecture  Dataflow  Mod¬ 
eling  Technique  (35)  (1).  Another  area  of  emphasis  is  Kirkpatrick’s  dissertation  efforts  relative 
to  nested-relational  DBMS.  The  nested-relational  IDEFo  implementation  depends  upon  Mankus’s 
development  of  a  nested-relational  DBMS  (23).  If  the  nested-relational  DBMS  is  not  robust  enough 
to  implement  the  nested-relational  design,  a  "paper  model"  will  be  constructed  and  used  as  the 
basis  for  comparison.  Finally,  the  ability  to  map  the  abstract  data  model  into  the  exis'ing  AFIT 
software  development  environment  is  of  concern  (16:8). 
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Sequence  of  Presentation 


This  thesis  consists  of  five  chapters.  An  overview  of  the  IDEFo  language,  and  the  Exodus 
extensible  DBMS,  as  well  as  a  literature  review  of  DBMS  as  each  applies  to  CASE  tool  data  is  pre¬ 
sented  in  Chapter  II.  The  design  of  the  IDEF0  abstract  data  model  and  the  corresponding  relational 
and  nested-relational  DBMS  implementations  are  presented  in  Chapter  III.  Chapter  IV  summarizes 
and  compares  the  IDEFo  implementation  within  a  relational  and  nested-relational  DBMS.  Finally, 
Chapter  V  presents  the  conclusions  of  this  research  effort  and  includes  recommendations  on  further 
research  in  this  area. 
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II.  LITERATURE  REVIEW 


Introduction 

rile  purpose  of  this  investigation  is  to  develop  an  abstract  data  model  of  the  IDEF0  language, 
implement  'he  data  model  within  a  relational  and  nested-relational  DBMS,  and  determine  if  there 
are  benefits  associated  with  the  nested-relational  implementation  of  the  model. 

Since  the  particular  language  being  implemented  is  IDEFo,  and  the  implementation  DBMS 
for  the  nested-relational  model  is  Exodus,  a  brief  overview  of  each  is  presented.  The  underlying 
issue  of  course,  is  to  determine  if  the  mapping  of  CASE  tool  data  into  a  DBMS  is  worthwhile. 
Accordingly,  a  literature  review  of  CASE  tools  and  their  connection  with  DBMS  is  conducted  to 
gain  some  insight  into  the  problem. 

Overview  of  IDEFo 

IDEFo  is  a  graphical  language  which,  among  other  things  can  be  used  during  the  analysis 
phase  of  software  development.  In  order  to  discuss  IDEFo,  it  is  necessary  to  also  discuss  Structured 
Analysis  (SA).  The  following  paragraphs  give  a  brief  overview  of  both  SA  and  IDEFo. 

In  his  1976  paper,  Douglas  Ross  introduced  Structured  Analysis  as  a  generalized  language, 
which  allows  a  complex  idea  to  be  represented  in  a  hierarchical,  top-down  representation  (30). 
According  to  Ross.  "The  human  mind  can  accommodate  any  amount  of  complexity  as  long  as  it 
is  presented  in  easy-to-grasp  chunks  that  are  structured  together  to  make  the  whole”  (30:17).  SA 
combines  graphic  features  such  as  lines  and  boxes  with  standard  written  language  to  create  the 
SA  model.  Figure  6  illustrates  the  basic  idea  behind  this  structured  decomposition.  At  each  level, 
o.ily  the  details  essential  for  that  level  are  given.  Further  details  are  exposed  by  moving  down  in 
the  hierarchy. 

SA  provides  for  two  kinds  of  decomposition,  an  activity  decomposition,  and  a  data  decompo- 
'itiou  In  the  activity  decomposition,  activities  (verbs)  are  represented  by  rectangular  boxes,  and 
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Figure  6.  Structured  Decomposition 

data  (nouns)  are  represented  by  arrows  flowing  into  and  out  of  the  boxes.  In  the  data  decomposi¬ 
tion.  boxes  represent  data,  and  arrows  represent  activities  operating  on  the  data  in  the  boxes.  An 
■  xample  of  an  activity  decomposition  is  shown  in  the  following  two  figures.  Figure  7  represents 
the  overall  context  of  the  system  being  analyzed  (the  so  called  "A  minus  zero"  diagram).  Figure  8 
represents  the  first  level  decomposition  (the  “A  zero"  diagram).  In  a  real  analysis,  the  AO  diagram 
would  be  further  decomposed  to  whatever  level  was  necessary  to  ensure  an  unambiguous  interpre¬ 
tation  of  the  system  requirements,  Marca  and  McGowan  have  written  an  excellent  book  which 
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Figure  7.  A-0  Diagram 

describes  SADT1  and  provides  numerous  workshop-style  examples  with  which  users  can  develop  a 
flavor  for  the  language  (24). 

A  full  implementation  of  Ross's  SA  includes  40  different  language  features,  and  the  dual  de¬ 
composition  (30:20).  But  the  United  States  Air  Force  Program  for  Integrated  Computer  Aided 
Manufacturing  (ICAM),  which  is  directed  towards  increasing  manufacturing  productivity  via  com¬ 
puter  technology,  defines  a  subset  of  Ross's  Structured  Analysis  language  called  ICAM  Definition 
Method  Zero,  or  just  IDEFo  (25)  This  functional  modeling  language  eliminates  some  of  the  more 
esoteric  features  of  Ross's  language,  as  well  as  the  data  decomposition.  Appendix  B  shows  the 
features  of  the  IDEFo  language 

According  to  the  IDEFo  manual 

1  .Structured  Analysis  and  Design  Technique  (SADT)  is  SofTech's  name  for  SA 
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The  ICAM  program  approach  is  to  develop  structured  methods  for  applying  computer 
technology  to  manufacturing  and  to  use  those  methods  to  better  understand  how  best 
to  improve  manufacturing  productivity.  . .  .IDEFo  is  used  to  produce  a  function  model 
which  is  a  structured  representation  of  the  functions  of  a  manufacturing  system  or  envi¬ 
ronment.  and  of  the  information  and  objects  which  interrelate  those  functions.  (25:1-1) 


One  of  the  problems  with  both  SA  and  IDEFo  is  that  there  does  not  appear  to  be  a  formal 
model  of  the  language.  In  addition  to  "blueprint-like  graphics,”  SA  and  IDEFo  call  for  the  use  of 
natural  language  (30).  The  use  of  such  natural  language,  by  definition,  introduces  ambiguity  in 
t  he  overall  IDEF0  language.  In  addition,  certain  graphical  features  of  IDEFo  allow  for  ambiguous 
models  to  be  constructed.  In  short,  IDEFo  is  not  a  rigorous  language.  Although  the  original  intent 
of  the  IDEFo  language  was  to  provide  a  structured  approach  for  computerizing  manufacturing  pro¬ 
cesses.  it  is  also  the  language  being  used  by  the  Strategic  Defense  Initiative  Organization  (SDIO)  to 
help  understand  the  requirements  for  the  so  called  “star  wars"  defense.  The  language  also  provides 


20 


an  analysis  methodology  for  the  requirements-phase  of  a  development  effort.  It  is  precisely  this 
use  of  IDEFo  as  a  software  requirements  methodology  which  was  the  motivation  for  developing  the 
data  model  presented  in  this  thesis.  In  addition,  the  model  helps  mitigate  some  of  the  ambiguities 
inherent  in  IDEFo- 

A  FIT  and  IDEFq 

The  Air  Force  Institute  of  Technology  (AFIT)  Department  of  Electrical  and  Computer  En¬ 
gineering  has  promulgated  a  set  of  system  development  guidelines  and  st  andards  which  encourage 
consistency  throughout  all  phases  of  hardware  and  software  systems  development  (16).  As  part 
of  this  standard,  and  in  conjunction  with  ongoing  efforts  to  utilize  computer  aided  software  en¬ 
gineering  (CASE)  in  the  software  engineering  curriculum,  the  department  selected  IDEFo  as  the 
language  of  choice  for  performing  systems  analyses.  The  IDEF0  language  was  extended  to  include 
a  data  dictionary,  which  is  AFIT’s  implementation  of  and  improvement  over  the  glossary  called  for 
by  IDEFo  It  provides  not  only  the  glossary,  but  also  a  more  syntactical  representation  of  some  of 
the  ambiguous  features  of  the  language. 

Several  past  efforts  have  produced  CASE  tools  to  assist  AFIT  students  during  software  de¬ 
velopment.  In  particular,  Johnson  developed  a  tool  called  SAtool,  based  upon  the  IDEFo  language, 
which  allows  the  software  engineer  to  perform  an  analysis  of  the  software  requirements  ( 19)  SAtool. 
which  runs  on  a  Sun  workstation,  is  a  graphics  based  editor  which  allows  the  analyst  to  draw  the 
diagrams  and  enter  portions  of  the  data  dictionary  for  the  requirements  analysis  phase  of  software 
development.  The  remaining  elements  of  the  data  dictionary  are  automatically  derived  from  the 
diagram.  The  user  can  generate  a  printout  of  the  SA  diagram,  a  so-called  facing-page  text  printout, 
and  a  hard-copy  printout  of  the  data  dictionary.  The  analysis  results  can  be  saved  in  a  standard 
data  file  for  uploading  into  a  common  database.  The  tool  also  saves  the  graphical  drawing  informa- 
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t  ion  so  the  user  can  recall  the  diagram  for  editing.  Figure  9  illustrates  some  of  the  SAtool  products, 
and  Appendix  C  contains  some  typical  examples  of  these  products. 

The  standard  data  file  generated  by  SAtool  can  be  uploaded  into  AFIT's  common  database 
According  to  Connally,  the  goal  of  the  common  database  system  is  to 

provide  an  integrated  system  in  which  a  designer  could  sit  down  at  a  workstation, 
download  the  necessary  data  from  a  central  database,  work  on  a  portion  of  the  design, 
and  when  finished,  upload  the  data  back  to  the  database.  (9:2) 

Overview  of  Eiodus 

There  are  several  ongoing  research  efforts  within  the  database  arena  which  are  attempting  to 
deal  with  non-traditional  database  applications.  There  seem  to  be  two  general  approaches:  build  a 
database  that  has  all  the  capabilities  needed  for  non-traditional  applications;  or  build  an  extensible 
database  that  can  be  tailored  to  the  needs  of  a  specific  application.  One  such  project,  which  falls 
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into  the  second  category,  is  the  University  of  Wisconsin's  Extensible  Object-oriented  Database 
System  (Exodus). 

Basically,  Exodus  can  be  perceived  of  as  a  toolkit  which  allows  an  application-specific  database 
to  be  constructed  on  top  of  an  existing  set  of  kernel  facilities.  Carey  provides  the  following  abstract 
description  of  Exodus: 


The  goal  of  this  project  is  to  facilitate  the  fast  development  of  high-performance, 
application-specific  database  systems.  Exodus  provides  certain  kernel  facilities,  includ¬ 
ing  a  versatile  storage  manager.  In  addition,  it  provides  an  architectural  framework 
for  building  application-specific  database  systems;  powerful  tools  to  help  automate  the 
generation  of  such  systems,  including  a  rule-based  optimizer  generator  and  a  persis¬ 
tent  programming  language;  and  libraries  of  generic  software  components  (e  g.,  access 
methods)  that  are  likely  to  be  useful  for  many  application  domains.  (4:1) 


The  Exodus  architecture  provides  the  following  tools  to  be  used  in  building  a  database: 


(1)  The  Storage  Manager. 

(2)  The  E  programming  language  and  its  compiler. 

(3)  A  library  of  type-independent  Access  and  Operator  Methods. 

(4)  A  rule-based  Query  Optimizer  Generator. 

(5)  Tools  for  constructing  query  language  front  ends  (4:3) 

It  is  Exodus's  toolkit  quality  which  makes  it  ideal  for  implementing  a  nested-relational  DBMS 
to  manage  the  data  associated  with  IDEFo-  Although  the  Wisconsin  researchers  have  already  built 
a  relational  DBMS,  called  Exrel,  using  the  Exodus  toolkit,  it  is  not  robust  enough  to  handle 
the  relational  implementation  of  IDEFo  (3).  The  nested  DBMS  built  by  Mankus  is  used  as  the 
implementation  media  for  the  nested-relational  version  of  the  IDEFo  database  (23). 


CASE  Tools  and  DBMS 

A  data  base  is  invariably  at  the  center  of  any  kit  of  CASE  tools.  As  experience  with  such 
•lata  bases  accumulates,  CASE  vendors  are  finding  more  ways  to  use  stored  information  to  aid 
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in  the  software-development  process.  Because  it  is  a  repository  for  the  specifications  developed 
during  t he  analysis  phase,  the  data  base  can  act  as  a  bridge  to  the  design  phase,  making  specific 
information  on  system  functions  available  while  the  design  is  being  partitioned  and  detailed.  As 
the  storage  place  for  the  data  elements  and  code  modules  that  make  up  the  final  design,  the  data 
base  becomes  the  source  for  reconfiguring  the  software  after  design  changes  and  for  reuse  of  code,  as 
well  as  specification  and  design  elements.  The  data  base  is  also  the  source  from  which  information 
for  documentation,  project  management  and  software  testing  is  drawn. 

An  Analysis  Scenario  -  The  Seed  for  a  DBMS.  The  following  scenario,  associated  with  the 
development  of  an  analysis  via  AFIT’s  SAtool,  demonstrates  an  initial  input  sequence,  modifi- 
'-ation  sequence,  and  several  queries.  The  section  closes  with  a  discussion  as  to  why  a  database 
management  system  might  be  useful  for  storing  the  data. 

CrLai  ..g  5.4  Diagrams.  The  following  is  a  brief  description  of  a  typical  SAtool  session. 
Using  tb'  graphics  based  SAtool  editor,  the  analyst  creates  the  A-0  top-level  diagram  shown  in 
Fie. ire  7.  The  graphics  frame  includes  attributes  such  as  author,  date,  revision  number,  project 
name,  the  title  of  the  diagram,  diagram  number,  and  node  number.  For  the  single  activity  box 
on  the  diagram,  there  are  several  attributes.  Examples  include  activity  name;  the  input,  output, 
control,  and  mechanism  arrows  attached  to  the  activity;  a  description  of  the  activity;  and  an 
activity  number.  Each  of  the  data  arrows  also  includes  several  attributes.  For  example,  data 
name,  description,  data  type,  range,  value,  and  composition  (data  arrows  nested  inside  another 
data  arrow).  Typically,  the  analyst  does  not  yet  know  the  composition  of  "high  level"  arrows;  more 
often  than  not,  this  is  determined  at  the  next  lower  level.  In  any  case,  after  drawing  the  boxes  and 
arrows  and  entering  all  of  the  known  data  associated  with  the  A-0  diagram,  the  analyst  then  saves 
the  drawing  data  in  a  flat  file  and  the  data  dictionary  data  in  another  flat  file. 

A  new  drawing  is  then  started  which  decomposes  the  parent  activity  box  to  expose  the  details 
in  the  next  level  as  shown  in  Figure  8.  Here  the  analyst  essentially  starts  over  again.  He  draws 
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all  the  boxes,  all  the  arrows,  enters  all  the  data  dictionary  items,  and  saves  the  result  to  another 
pair  of  flat  files.  Notice  that  much  of  the  information  on  the  AO  diagram  is  the  same  as  on  the  A-0 
diagram. 


Modifying  an  SA  Diagram.  Suppose  the  analysis  documents  need  to  be  modified.  For 
example,  a  requirement  to  handle  dates  gets  added.  The  analyst  must  open  the  file  for  the  A-0 
diagram  and  edit  the  data  dictionary  for  the  three  data  arrows  userdata,  rules,  and  feedback  to 
include  udate,  daterules,  and  datemsgs  respectively,  in  the  composition  fields.  He  would  enter 
the  new  revision  number  and  date  and  then  save  the  results  (if  the  old  version  was  required  as 
history,  its  files  would  have  to  be  saved  elsewhere).  The  analyst  would  then  open  the  AO  diagram, 
add  a  new  activity  box  manage  date  data,  and  add  the  new  data  arrows  between  userdata, 
rules,  feedback  and  this  new  activity  box.  He  would  enter  all  the  data  dictionary  requirements 
for  the  new  arrows  and  activity  box,  and  save  the  results. 

Querying  an  5.4  Diagram.  Obviously  there  will  be  a  number  of  predetermined  "stan¬ 
dard"  queries  associated  with  the  SA  diagram.  For  example,  the  queries  needed  to  extract  the 
drawing  data,  or  the  queries  needed  to  move  from  one  level  to  another,  or  the  queries  needed  to 
determine  the  data  content  of  a  parent  arrow.  Certainly,  even  without  the  use  of  a  DBMS,  it  is 
possible  to  write  these  standard  queries  in  some  high-level  language  and  make  them  available  to  the 
tool  user  via  the  standard  tool  interface  mechanism.  However,  ad  hoc  queries  are  another  matter. 
Let's  look  at  several  queries  that  might  be  typical  for  an  SA  analysis  (these  queries  are  based  on 
my  own  personal  experience  with  software  analyses  in  general,  and  with  SA  in  particular).  Suppose 
tie-  analyst  is  interested  in  determining  all  of  the  activity  boxes  which  are  touched  by  the  userdata 
data  arrow.  This  is  currently  done  by  painstakingly  examining  each  diagram  and  manually  tracing 
the  arrows.  There  is  no  effective  way  of  accomplishing  this  via  the  current  automated  tool.  Sup¬ 
pose  the  analyst  is  interested  in  all  the  primitive  (lowest  level)  activities  within  a  certain  activity 
box.  Once  again  this  must  be  done  by  manually  looking  at  each  of  the  subordinate  diagrams  and 
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extracting  the  activity  boxes  which  have  no  ‘‘children."  Suppose  a  certain  analyst  on  the  team  gets 
promoted.  His  replacement,  Mary,  needs  to  know  which  diagrams  now  belong  to  her.  This  would 
currently  be  done  by  manually  examining  each  diagram  to  determine  the  author  Finally,  suppose 
the  project  manager  needs  to  determine  which  diagrams  were  modified  after  a  certain  date.  Once 
again  this  would  be  done  by  manually  examining  each  and  every  diagram. 

Why  a  DBMS  Would  be  Useful.  The  previous  sections  consider  a  typical  analysis  sce¬ 
nario  in  terms  of  creating,  modifying,  and  querying  the  analysis  products.  Some  of  the  problems 
associated  with  the  current,  non-DBMS  implementation  of  SAtool  are  illustrated.  This  section 
suggests  that  a  DBMS  might  be  useful  in  providing  a  solution  to  each  of  the  problems. 

Consider  the  initial  creation  of  the  AO  diagram.  Clearly,  much  of  the  information  needed 
on  the  diagram  is  already  available  from  the  previously  generated  A-0  diagram.  For  example;  the 
project  name,  title,  etc.,  should  be  propagated  down  to  subordinate  levels.  Unfortunately,  the 
current  implementation  of  SAtool  requires  the  user  to  enter  all  of  this  information  at  each  level.  As 
a  msult.  there  is  a  significant  amount  of  redundant  data  stored  for  each  level  of  the  diagram.  Say 
that  an  analysis  consists  of  N  levels,  and  at  each  level  (except  the  A-0).  there  are  k  boxes.  Assume 
that  the  only  redundant  data  is  the  project  name.  It  gets  stored  once  at  the  A-0  level,  k°  times  at 
level  0  (AO),  k~  times  at  the  level  1  (nodes  A1  through  Ak),  k -  times  at  level  2  (nodes  All  through 
Akk).  k3  times  at  level  3  (nodes  A 1 1 1  through  Akkk),  . . . ,  klW  times  at  level  N.  Adding  this  all  up 
we  see  that  the  same  piece  of  data  has  been  redundantly  stored  Rs  times,  where 

A  1  -  i fc-v+l 

R»  =  i+Y,k>  = 1  +  l_k 
1=0 

The  formula  above  is  conservative;  SAtool  actually  saves  project  name  for  each  box  and  for 
each  data  arrow!  The  simple  2-level  analysis  depicted  in  the  two  SAtool  figures  results  in  a  flat  data 
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file  which  contains  the  project  name  "DM  Example”  14  times.  If  this  information  were  available 
in  a  database,  it  could  simply  be  referenced  by  the  subordinate  level  diagram. 

Aside  from  the  redundant  storage  issue,  there  is  the  high  potential  for  incorrect  data  entry 
All  of  the  input  is  done  manually  at  each  level;  no  consistency  checking  is  done.  It  is  possible 
to  create  diagrams  that  absolutely  do  not  match  at  the  various  levels.  A  DBMS,  which  typicalk 
includes  consistency  validation  routines,  could  help  mitigate  this  problem. 

The  modification  scenario  presented  above  could  be  significantly  simplified  by  the  use  of  an 
appropriate  DBMS.  When  the  analyst  decomposes  a  pipe  data  element  into  its  constituent  data 
elements,  their  names,  et  al,  would  be  automatically  propagated  upward  into  the  higher  level 
diagrams.  As  already  mentioned,  it  is  currently  possible  to  decompose  an  arrow  (data  item)  at  a 
lower  level  and  then  not  update  it’s  "parent”  arrow.  The  fact  is  that  an  IDEFq  analysis,  being 
a  top-down  approach,  gradually  exposes  more  detail  as  one  moves  down  the  hierarchy.  Generally 
speaking,  the  analyst  does  not  even  know  the  composition  of  a  given  "high  level"  data  arrow  until 
the  lower  level  diagrams  are  drawn.  Accordingly,  the  analysis  typically  goes  something  like  this; 
draw  the  high  level  diagram  and  save  it.  Draw  the  lower  level  diagrams  and  save  them.  Reopen 
the  high  level  diagram  and  add  the  correct  composition  to  arrows  Clearly  this  redundant  effort 
might  be  eliminated  by  the  use  of  a  DBMS. 

The  queries  discussed  above  could  also  benefit  from  a  DBMS.  The  drawing  tool  could  use  an 
embedded  version  of  the  DBMS  query  language  to  extract  and  draw  the  diagrams.  The  user  could 
■'mploy  the  query  language  of  the  database  manager  to  extract  information.  Stored  queries  could 
lie  maintained  for  those  queries  which  occur  frequently;  ad  hoc  queries  could  be  constructed  on  the 
lly  Finally,  the  use  of  a  DBMS  would  automatically  provide  for  crash  recovery  and  concurrency 
control  for  multiuser  applications. 

Mapping  Difficulties.  It  is  certainly  not  yet  clear  that  the  nested-relational  DBMS  is  the 
answer  to  all  the  problems  associated  with  mapping  CASE  tool  data  into  a  DBMS.  At  the  risk  of 
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appearing  prejudiced  against  relational  databases,  I  would  like  to  illustrate  some  of  the  problems 
that  arise  when  using  a  relational  DBMS  in  a  CASE  tool  data  environment.  For  example,  a  design 
object  may  be  physically  too  large  to  fit  in  a  standard  record,  and  if  a  single  design  object  is 
represented  by  many  records,  the  user  must  still  be  able  to  manipulate  it  as  if  it  were  a  single  unit. 
In  addition,  different  users  may  want  different  views  of  the  same  object.  One  user  might  want  to 
see  a  high-level  data-flow  view  of  the  "Guide-Torpedo"  system,  whereas  another  user  might  want 
to  see  only  the  processes  associated  with  "Guide-Torpedo,”  or  perhaps  only  the  main  routine  from 
the  design  phase  data  dictionary. 

One  of  the  biggest  problems  associated  with  mapping  CASE  data  into  a  relational  model  is 
that  the  record  oriented  relational  model  forces  the  designer  to  oversimplify  data  structures  to  the 
extent  that  information  about  the  database  is  lost.  Logical  entities  must  be  broken  up  into  many 
relations  in  order  to  "force  fit”  them  into  the  relational  model.  This  typically  results  in  a  large 
number  of  relations  and  tuples.  In  a  design  phase  database,  for  example,  the  code  of  a  module 
body  typically  involves  perhaps  100  lines.  Assume  that  each  line  is  restricted  to  an  80-column 
format  Clearly  we  would  need  to  map  this  into  100  tuples  each  having  (among  other  fields)  an  80 
character  string  field.  In  order  to  retrieve  the  single  logical  entity  called  "code  body,”  we  would 
have  to  retrieve  100  tuples  from  the  database  and  then  (somehow)  force  these  lines  into  a  single 
text  file.  Figure  10  is  an  admittedly  simplified  E-R  diagram  of  the  SAtool  data  model.  There  are 
essentially  two  entities;  activity  boxes,  and  data  arrows.  Nonetheless,  when  we  map  this  into  a 
relational  model,  we  end  up  with  some  23  different  relations  as  shown  in  Appendix  D.  A  direct 
consequence  of  this  mapping  is  that  query  processing  is  slowed  down  by  virtue  of  the  multiple  joins 
n-quiied. 

Another  problem  associated  with  mapping  CASE  data  into  a  relational  model  is  the  length 
(time  wise)  of  transactions.  In  a  typical  business  application,  a  transaction  only  lasts  a  few  mo¬ 
ments.  The  user  grabs  the  applicable  tuples,  immediately  makes  changes  to  them  and  writes  them 
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Figure  10.  Highly  Simplified  E-R  Diagram  of  SAtool  Data  Model 


hack  to  the  database.  In  CASE  tools  however,  the  user  checks  out  the  appropriate  diagram  (tu¬ 
ples').  and  then  may  spend  hours  if  not  days  making  changes  before  checking  in  the  results.  In  a 
typical  relational  DBMS,  this  might  seriously  impact  the  crash  recovery  capability  of  the  system 

Yet  another  problem  when  mapping  CASE  data  into  a  relational  model  is  that  of  keeping 
revisions  (history).  A  typical  software  development  effort  requires  the  developer  to  keep  all  revisions 
in  the  database.  Thus,  when  we  “update"  a  logical  entity,  we  might  be  adding  a  new  feature  to  the 
'•utity,  or  we  may  be  simply  changing  an  existing  feature,  i.e.,  the  meaning  of  the  word  “update" 
is  now  ambiguous.  A  similar  problem  exists  with  ’delete;"  say  a  certain  revision,  y,  requires  us  to 
delete  module,  x  Clearly  we  want  to  keep  the  entities  associated  with  module  x  in  the  database 
for  revisions  earlier  than  y,  and  "delete”  them  for  revisions  v  and  beyond 

As  a  result  of  these  mapping  problems  (and  perhaps  others),  existing  database  technology 


forces  many  CASE  vendors  to  defer  to  the  file-based  structures  that  early  business  applications 
used .  The  current  generation  of  CASE  tools,  for  the  most  part,  are  special-purpose  systems  in 
which  a  collection  of  files  represent  design  objects.  The  primary  drawbacks  of  this  approach  are 
the  lack  of  data  independence,  the  complexity  of  database  administration,  the  high  degree  to  which 
the  data  is  tied  to  the  machine  representation  and  internal  data  structures,  and  the  lack  of  fully 
general  concurrency  and  recovery  systems.  These  drawbacks  are,  in  many  respects,  identical  to 
those  encountered  by  data-processing  applications  before  database  management  systems  came  into 
widespread  use. 

Commercial  Databases  for  CASE  Tools.  There  are  a  few  vendors  who  have  developed  databases 
tailored  specifically  towards  the  needs  of  CASE  tools.  Three  such  systems  are  briefly  described  in 
the  following  paragraphs. 

CDD/Plus.  The  VAX  Common  Data  Dictionary,  CDD/Plus ,  developed  by  Digital 
Equipment  Corporation  (Marlboro,  MA),  is  a  distributed  data  dictionary  which  allows  users  access 
to  software  data  definitions  either  centrally  or  locally  across  a  network.  It  spans  the  entire  software 
life  cycle-from  applications  development  and  code  generation,  through  production  and  systems 
implementation  ft  allows  data  extraction  to  simplify  software  documentation  efforts,  and  allows 
ad  hoc  analysis  and  reporting  (37). 

The  Developer.  The  Developer,  available  from  Asyst  Technologies.  Montreal,  Canada, 
lets  the  user  construct  simple  diagrams  consisting  of  rectangles,  interconnecting  lines  and  arrows, 
and  text.  In  addition  to  storing  items  such  as  data  elements  and  data-flow  descriptions,  a  data  base 
rout.  , ns  attribute  information  for  each  item,  as  well  as  associations  between  stored  items.  The  user 
•■an  deride  not  only  which  items  to  store,  but  also  what  attributes  the  items  will  have  and  what 
the  rules  will  be  for  associations  between  the  items  (17). 
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vsDesigner.  vsDesigner,  from  Visual  Software,  Santa  Clara,  C A.  is  a  highly  flexible 
database  oriented  specifically  towards  the  CASE  market.  It  is  object-oriented  and  lets  users  define 
the  objects  and  object  attributes.  Associations  between  objects  can  also  be  defined  in  the  form 
of  rules.  Each  object  has  multiple  user-defined  representations:  graphics  symbols,  object  descrip¬ 
tions.  rules  for  using  it  with  other  objects,  and  attributes.  During  analysis,  users  can  install  links 
in  specification  objects  that  will  later  be  connected  to  design  objects.  Source  code  can  also  be 
associated  with  each  object,  along  with  attributes  such  as  execution  times.  With  the  help  of  a  data 
base  query  language  called  vsSQL,  users  can  make  execution-time  analysis  of  real-time  software  by 
walking  through  the  branches  of  the  software  design  and  summing  the  object  execution  times  (17) 

Integration  of  CASE  Tools.  CASE  tools  are  providing  substantial  productivity  gains  during 
the  initial  phases  of  software  development,  but  CASE  tools  haven't  generally  been  integrated  with 
software  coding,  debugging  or  testing.  This  is  largely  due  to  the  file  based  architectures  discussed 
previously.  Nonetheless,  there  are  some  ongoing  attempts  to  alleviate  this  problem  and  provide 
data  availability  across  all  phases  of  the  development  effort.  The  following  paragraphs  provide 
insight  into  some  of  these  efforts. 

Standardized  File  Interchange  Solution.  One  effort  to  solve  the  problem  of  CASE  con¬ 
nectivity  has  been  proposed  by  Cadre  Technologies  (Providence,  Rl),  a  leading  CASE  vendor. 
Their  proposal  has  been  submitted  to  the  Electronic  Design  Interchange  Format  (EDIF)  Techni¬ 
cal  Subcommittee,  which  makes  recommendations  on  standards  to  the  American  National  Stan¬ 
dards  Institute  (ANSI).  EDIF  Review  Process  Committee  members  include  a  rather  impressive 
list  of  well-known  companies  including;  Advanced  Technologies  Applications,  the  Aerospace  Corp  . 
Apollo  Computer.  Applied  Microsystems,  Atherton  Technology,  Cadre  Technologies.  Deere  and 
Co  .  E-Systems,  Expertware,  Hewlett-Packard,  Index  Technology.  Integrated  Data  Ltd.,  I-Logics. 
Mark  V  Ltd..  Pro.Mod,  Ready  Systems,  Sage  Software,  and  Textronix.  The  benefits  of  an  EDIF 
standard,  according  to  Vizard,  will  include  more  competition  among  CASE  tool  vendors,  greater 
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compatibility  among  products,  increased  specialization  for  particular  CASE  tools,  better  bench¬ 
mark  comparisons,  and  greater  integration  between  contractors  and  subcontractors,  irrespective  of 
the  CASE  tools  they  are  using  (39).  Basically,  this  adaptation  of  the  ED1F  standard  will  allow 
each  tool  vendor  to  exchange  data  through  a  standardized  interchange  file  format  Unfortunately, 
the  standard  has  not  yet  been  approved  by  all  parties. 

Microprocessor  System  Development  Solution.  To  provide  CASE  tool  integration  within 
the  embedded  system  development  arena,  Microcase  (Beaverton,  OR)  is  teaming  up  with  Cadre 
Technologies.  Microcase  manufactures  the  Software  Analysis  Workstation,  an  IBM  PC-based  sys¬ 
tem  that  provides  performance  optimization  and  verification  for  embedded  software.  The  two  com¬ 
panies  are  now  developing  an  interface  that  will  let  data  from  the  Software  Analysis  Workstation  be 
captured  by  Cadre's  data  base.  Microcase  also  sells  compilers,  debuggers,  and  in-circuit  emulators 
The  partnership  with  Cadre  gives  Microcase  the  opportunity  to  build  a  complete  microprocessor 
development  solution,  from  front-end  CASE  tools  to  coding,  hardware-software  integration,  and 
test  (14). 


VAX/C DD-Eicelerator  Solution.  There  are  other  ongoing  efforts  to  integrate  CASE 
fools  across  the  software  life  cycle.  Index  Technology  has  developed  a  link  integrating  its  systems 
analysis  and  design  software,  Ezcelerator/IS,  with  the  VAX  Common  Data  Dictionary,  CD  D/Plus. 
Excelerator/IS  is  the  preeminent  CASE  system  for  commercial  systems  analysis  and  design.  CDD/Plus 
was  discussed  in  the  previous  section  (37). 

.4  Generic  DBMS  Solution.  Goering  discusses  a  standardization  effort  undertaken  by 
Atherton  Technology  (Sunnyvale,  CA)  and  Digital  Equipment  Corporation  (Marlboro,  MA)  (15:28) 
Their  solution,  currently  called  ATIS,  involves  defining  a  way  for  tools  to  link  into  a  consistent  data- 
mauagement  system.  The  ultimate  result  will  be  a  public-domain,  nonproprietary  database  stan¬ 
dard.  Companies  involved  include  Atherton  Technology,  Digital  Equipment  Corporation.  Apollo 
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Computer.  Cadre  Technologies,  Ford  Aerospace,  Hewlett-Packard,  IBM,  Index  Technology,  Inter¬ 
active  Development  Environments,  Interleaf,  RCA,  Rockwell,  and  Sun  Microsystems.  This  effort 
attempts  to  accomplish  the  same  goal  as  the  proposed  EDIF  standard  previously  discussed.  How¬ 
ever.  the  ATIS  effort  allows  a  so-called  “deeper  level  of  integration"  by  defining  a  common  way  of 
managing  multivendor  data,  as  opposed  to  the  simple  data  interchange  format  proposed  by  Cadre’s 
EDIF  solution.  ATIS  defines  an  object  oriented  methodology  that  provides  an  interface  between 
CASE  tools  and  data-management  services,  and  it  establishes  models  for  such  procedures  as  version 
control,  security  and  access  control,  and  transaction  control.  According  to  Goering, 


The  tool  interface  is  based  upon  a  predefined,  single-inheritance  hierarchy  of  data  types. 
As  is  typical  in  object-oriented  programming,  each  type  has  associated  messages  (such 
as  open,  merge  and  check-in),  methods  (pieces  of  code  that  implement  messages)  and 
properties  (such  as  child  and  parent).  To  add  a  new  tool,  the  tool  integrator  can  either 
use  existing  types  or  add  a  new  subtype.  A  new  subtype  can  inherit  existing  methods 
and  messages,  or  new  methods  and  messages  can  be  added.  A  tool  that’s  designed  with 
ATIS  in  mind  can  be  integrated  more  efficiently  than  an  existing  tool.  By  supporting 
the  predefined  types,  the  tool  can  exchange  data  more  efficiently  and  avoid  duplicating 
storage.  ATIS  doesn’t  mandate  a  specific  system  for  implementing  a  management  ser¬ 
vice,  nor  does  it  dictate  a  specific  type  of  data  base.  It  does  however,  set  forth  some 
conceptual  models  that  describe  the  execution  of  messages.  Under  the  current  version 
control  model,  for  example,  two  users  can  open  a  file  concurrently  and  update  it  locally. 
After  the  files  are  checked  in,  the  management  system  merges  them  into  a  new  version. 
ATIS  provides  several  types  of  models  including  those  for  security  and  access  control, 
which  determines  who  has  clearance  to  access  data;  those  for  naming  services,  which 
establish  a  file  naming  methodology;  and  those  for  transaction  control,  which  guarantee 
data  base  consistency  during  concurrent  multiuser  access.  The  ATIS  group  also  plans 
to  address  correspondence  control,  which  establishes  relationships  between  objects  in 
the  database.  Another  area  that  will  be  considered  is  data  access  and  communication 
across  a  network.  (15:28) 


A  FIT's  Common  Database  Interface  Solution.  Many  of  the  same  problems  being  ad¬ 
dressed  in  the  commercial  marketplace  are  also  being  addressed  by  the  Software  Engineering  Lab¬ 
oratory  here  at  AFIT.  In  his  recent  thesis  effort,  Connaliy  designed  and  built  an  interface  into  an 
Ingres  database  which  captures  information  from  the  analysis,  design,  and  coding  phases  of  the 
-oft ware  life  cycle  (9:9).  Figure  II  illustrates  Connally’s  basic  idea.  The  system  allows  the  require¬ 
ments  phase  data  dictionary  editor,  the  design  phase  data  dictionary  editor,  the  coding  phase  data 
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dictionary  editor,  and  the  SAtool  editor  to  communicate,  via  a  standard  data  file,  with  a  central¬ 
ized  database.  In  theory,  his  system  provides  an  ideal  solution.  However,  several  issues  complicate 
things.  First,  the  analysis  tool,  SAtool,  runs  on  a  Sun  workstation  and  the  Data  Manager  runs 
on  a  VAX  11/780.  This  requires  network  transfer  of  Connally’s  standard  data  file.  Also,  the  data 
is  being  captured  in  a  relational  database.  This  requires  a  large  number  of  relations  as  discussed 
earlier.  As  a  result,  the  transfer  of  data  to  and  from  the  Ingres  database  takes  10  -  15  minutes  per 
>ession.  In  short,  we  have  less  than  an  ideal  solution.  Appendix  E  includes  a  typical  Data  Manager 
-session. 


(9:28) 

Figure  11.  Common  Database  System  Structure 
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Sn  mm  ary 


This  chapter  presents  a  brief  overview  of  the  IDEFo  language,  and  the  Exodus  extensible 
DBMS  It  also  investigates  the  use  of  database  management  systems  to  support  computer  aided 
software  engineering  (CASE)  tools.  The  connection  (or  lack  of  connection)  between  CASE  tools 
and  DBMS  is  considered.  Since  many  commercial  CASE  tools  do  not  seem  to  use  relational  DBMS 
in  their  implementation,  and  in  light  of  the  difficulties  illustrated  in  this  chapter,  one  can  infer 
that  current  relational  technology  may  not  be  the  ideal  way  to  manage  CASE  tool  data.  The 
A  FIT  SAtool  scenario  establishes  that  CASE  tools  could  definitely  benefit  from  the  use  of  a  DBMS 
because  of  the  reduced  data  redundancy,  crash  recovery,  concurrency  control,  and  ease  with  which 
ad  hoc  queries  can  be  made.  Obviously,  it's  not  yet  clear  as  to  whether  the  nested-relational  DBMS 
will  actually  provide  a  tractable  solution. 

The  chapter  points  out  three  commercialized  databases  explicitly  designed  for  use  by  CASE 
tools.  It  looks  at  several  attempts  to  provide  CASE  tool  integration  across  the  entire  software  life 
cycle;  included  were  of  AFIT’s  ongoing  efforts  in  the  area. 
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III.  METHODOLOGY 


Introduction 

The  IDEFo  abstract  data  model  and  its  relational  and  nested-relational  DBMS  implemen¬ 
tations  are  presented  in  this  chapter.  After  introducing  certain  notational  adaptations  to  Chen's 
entity-relationship  analysis  methodology,  an  E-R  analysis  is  used  to  develop  an  abstract  data  model 
of  IDEFo.  This  model  helps  mitigate  some  of  the  ambiguities  inherent  in  IDEF0.  The  model  is 
divided  into  two  parts  representing  the  analysis  data  (the  essential  data  model)  and  the  graphical 
data  (the  drawing  data  model).  This  dual  modeling  approach  allows  for  the  extraction  of  analysis 
data  without  having  to  deal  explicitly  with  the  IDEFo  graphical  language.  Relations  corresponding 
to  the  E-R  diagrams  are  then  developed,  stepwise  refined,  and  mapped  into  a  relational  database 
design.  An  example  database  instance  is  developed.  The  relational  design  is  implemented  within 
Ingres  Corporation’s  relational  DBMS  (Ingres)  and  loaded  with  the  example  data.  SQL  queries  are 
developed  to  extract  drawing  data  and  essential  data  from  the  database.  The  relational  design  is 
transformed  into  a  nested-relational  design.  The  relational  database  instance  is  transformed  into 
a  nested-relational  instance.  SQL/NF  queries  are  developed  to  extract  drawing  data  and  essential 
data  from  the  nested-relational  database. 

Extended  E-R  Notation 

As  mentioned  earlier,  Codd’s  relational  data  model  is  the  de  facto  database  standard  (7). 
However,  several  other  models  have  been  proposed,  including  Chen’s  entity-relationship  (E-R) 
model  (6).  The  E-R  model  includes  the  concepts  of  entities  (represented  by  rectangles),  attributes 
(represented  by  ellipses),  relationships  (represented  by  diamonds),  and  the  links  between  them 
(represented  by  lines).  One  of  the  advantages  of  the  entity-relationship  model  is  that  it  allows 
for  easy1  mapping  into  a  relational  design.  An  E-R  diagram  based  upon  an  example  in  Date 

1  Many  E-R  design  tools  actually  do  this  mapping. 
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Figure  12.  Modified  Entity-Relationship  Notation 

is  shown  in  Figure  12  (10).  This  drawing  illustrates  certain  extensions  to  Chen's  E-R  notation 
which  make  the  E-R  diagrams  more  understandable  by  humans.  In  particular,  a  line  is  added  on 
the  side  of  the  relationship  construct  to  clarify  how  it  relates  to  the  corresponding  entities.  For 
example.  Figure  12  is  read  "supplier  supplies  parts."  Additionally,  the  cardinality  is  now  explicit, 
for  example,  Figure  12  is  read,  "supplier  supplies  zero  to  many  parts,"  and  “parts  are  supplied  by 
one  to  many  suppliers,"  Finally,  an  asterisk  is  associated  with  the  attribute  which  serves  as  the 
key.  eg.  s#  is  the  key  attribute  for  entity,  supplier. 

IDEFq  Abstract  Data  Model 

In  order  to  facilitate  development  of  a  DBMS  implementation  of  the  IDEFo  language,  an 
abstract  data  model  of  the  language  is  constructed.  This  abstract  data  model  consists  of  two  parts, 
the  essential  data  model,  and  the  drawing  data  model;  the  concept  is  illustrated  in  Figure  13.  This 
■  Inal  modeling  approach  allows  for  the  extraction  of  analysis  data  without  having  to  deal  explicitly 
with  the  IDEFo  language,  i.e.,  without  having  to  "walk  through"  the  various  drawings. 

The  IDEFo  essential  data  model  captures  those  portions  of  the  language  which  represent  the 
underlying  semantics  of  a  particular  analysis  (an  IDEFo  analysis  could  actually  be  represented  by 
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Figure  13.  IDEFo  Abstract  Data  Model:  Essential  Data  and  Drawing  Data 

infinitely  many  drawings  by  just  moving  one  box  a  little  on  the  diagram).  Perhaps  an  analogy  will 
better  explain  the  concept.  Say  a  good  friend  is  going  on  a  trip,  and  you  wish  to  bid  him  goodbye. 
1  here  are  any  number  of  different  ways  this  could  be  done.  A  card  that  says  “good  riddance,”  a  kiss, 
a  handshake,  a  bon  voyage  party,  etc.  Now  clearly,  each  of  these  actions  is  syntactically  different, 
yet  they  all  convey  to  the  human  the  same  semantics,  i.e.,  “goodbye.”  In  a  similar  sense,  an  IDEF0 
analysis  may  be  syntactically  expressed  any  number  of  ways,  yet  still  convey  the  same  semantical 
information  to  a  human  interpreter.  It  is  this  underlying  "essential”  data  which  is  captured  by 
the  essential  data  model.  This  includes,  for  example,  activities  and  their  children,  as  well  as  data 
elements  and  their  children.  It  does  not  include,  for  example,  the  location  of  the  boxes  or  arrows 
winch  graphically  represent  the  activities  and  data  elements. 

The  drawing  data  model,  on  the  other  hand,  encapsulates  the  graphical  constructs  which 
represent  the  particular  IDEFo  analysis.  It  contains  such  information  as  the  location  of  the  boxes 
which  graphically  represent  activities,  the  line  segments  which  graphically  represent  data  elements, 
various  other  graphics  artifacts,  such  as  the  location  of  “squiggies,”  the  location  of  footnote  markers. 
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some  of  the  graphics  "short-hand”  such  as  double  headed  arrows,  etc.  This  drawing  data  is  used 
to  actually  draw  an  IDEFo  diagram. 

The  entity-relationship  method  is  used  to  represent  both  the  essential  data  model  and  the 
drawing  data  model  since  it  retains  many  of  the  semantics  (for  a  human  interpreter)  of  the  actual 
data  being  modeled. 

Essential  Data  Model.  As  described  earlier,  the  IDEFo  essential  data  model  captures  those 
portions  of  th<*  language  which  represent  the  underlying  semantics  of  a  particular  analysis.  This 
includes,  for  example,  activities  and  their  children,  as  well  as  data  elements  and  their  children.  It 
does  not  include,  for  example,  the  location  of  the  boxes  or  arrows  which  graphically  represent  the 
activities  and  data  elements. 

In  order  to  allow  for  an  understandable,  yet  complete  representation,  the  E-R  analysis  of  the 
essential  data  model  is  done  in  two  parts  that  complement  one  another.  The  first  part  shows  the 
activity  model,  with  the  details  about  data  elements  left  out.  The  second  part  shows  the  data 
element  model  while  leaving  out  the  details  about  the  activities. 

Figure  14  illustrates  the  essential  model  associated  with  IDEF0  activities  and  Figure  15 
illustrates  the  essential  model  associated  with  IDEFo  data  elements.  Each  of  the  entities  and 
relationships  for  both  E-R  diagrams  is  explained  in  Table  I.  Most  of  the  attributes  include  a 
reference  to  show  why  the  given  attribute  was  necessary. 
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Table  1.  Description  of  Components  in  the  Essential  Data  Model 


E-R  construct 

description  1 

activity 

This  weak  entity,  which  is  existence  dependent  upon  project,  represents 
the  IDEFo  activities.  Attribute  node  number  is  the  discriminant,  and  name 
captures  the  name  of  the  given  activity  (24:13-14).  Attribute,  description. 
allows  the  analyst  to  describe  the  activity  (16:12). 

composed  of 

This  relationship  shows  that  a  given  parent  activity  is  composed  of  zero  to 
many  (0:m)  child  activities.  It  also  shows  that  each  activity  has  one  parent 
activity.  The  0:1  notation  accounts  for  the  fact  that  the  A-0  activity  does 
not  have  a  parent  activity  (16:12).  j 

analyst 

This  entity  is  used  to  capture  information  about  the  analyst  who  performed 
the  analysis.  The  reason  for  making  analyst  an  entity,  rather  than  an  at- 
tribute  of  activity,  is  so  that  it  might  be  tied  into  a  personnel  database.  The 
entity,  analyst,  currently  has  the  single  attribute,  author ,  which  identifies 
the  person  who  performed  the  analysis  (16:12). 

analyzes 

i 

This  relationship  expresses  the  fact  that  a  given  analyst  analyzes  zero  to 
many  activities  (or  data  elements).  Note  that  the  current  model  only  allows 
an  activity  (data  element)  to  be  analyzed  by  one  analyst.  Attribute,  ver¬ 
sion,  is  used  to  record  version  information;  date  indicates  when  the  analysis 
was  performed;  changes  captures  change  information  about  a  given  activity 
(data  element)  (16:12). 

project 

1 

This  entity  identifies  the  project  to  which  each  activity  (data  element)  is 
assigned.  Key  attribute,  pname,  indicates  the  name  of  the  project  (16:12). 

part  of 

This  relationship  indicates  that  an  activity  (data  element)  is  part  of  ex¬ 
actly  one  project,  whereas  a  project  contains  one  to  many  activities  (data 
elements). 

ref 

! 

: 

i 

! 

This  entity  captures  any  references  associated  with  an  activity  (data  el¬ 
ement).  Key  attribute,  reference,  identifies  which  reference  is  involved, 
and  attribute,  type,  identifies  the  type  of  reference  (16:12).  Basically,  this 
entity  allows  a  library  of  various  documents  such  as  DoD  standards,  user 
requirements,  contractual  clauses,  etc.,  to  be  tied  to  the  given  activity  (data 
element). 

based  on 

' 

1 

This  relationship  indicates  that  a  given  activity  (data  element)  is  based  on 
one  to  many  references,  and  that  a  given  reference  is  the  basis  for  zero  to 
many  activities  (data  elements). 

i  historical  activity 

i 

1 

This  entity  is  primarily  used  as  a  convenience  so  that  the  database  does  not 
have  to  be  loaded  with  analyses  which  were  previously  accomplished.  At¬ 
tribute,  project,  indicates  which  project  contains  the  historical  activity,  and 
attribute,  node  number,  identifies  the  specific  activity  within  the  project 
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Table  l  (continued):  Description  of  Components  in  the  Essential  Data  Model 


E-R  construct 

description 

calls 

This  relationship  indicates  the  fact  that  an  activity  can  call  zero  to  many 
previously  completed  (historical)  activities,  and  that  a  given  historical  ac¬ 
tivity  is  called  by  one  to  many  activities  (30:33). 

inputs 

This  relationship  indicates  that  an  activity  can  input  zero  to  many  data 
elements.  Ross's  SA  (and  the  IDEFo  subset)  only  require  activities  to  have 
control  data  elements  and  output  data  elements  (30:20).  Note  that  the 
entity,  data  element,  is  expanded  in  the  next  section. 

outputs 

This  relationship  shows  that  an  activity  must  have  at  least  one  but  can 
have  many  output  data  elements  (30:22). 

is  controlled  by 

This  relationship  shows  that  an  activity  can  have  one  to  many  control  data 
elements  (30:22). 

is  mechanized  by 

_ 

This  relationship  indicates  that  an  activity  can  have  zero  to  many  mecha¬ 
nism  data  elements.  Ross’s  SA  (and  the  IDEFo  subset)  only  require  activ¬ 
ities  to  have  control  data  elements  and  output  data  elements  (30:20). 

data  element 

This  weak  entity,  which  is  existence  dependent  upon  project,  represents 
the  IDEFo  data  elements.  Attribute,  name,  which  is  the  name  of  the  data 
element,  is  the  discriminant  (24:14).  Attribute,  description ,  allows  the 
analyst  to  describe  the  data  element  (16:12). 

pipe 

i 

This  entity  is  a  specialized  data  element,  as  illustrated  via  the  ISA  construct 
on  the  E-R  diagram.  It  has  no  additional  attributes,  but  merely  indicates 
that  the  data  element  is  actually  a  pipe  containing  at  least  two  other  data 
elements  (30:20). 

consists  of 

!  atomic  data  item 

This  relationship  shows  that  a  pipe  consists  of  at  least  two  data  elements, 
and  that  a  data  element  can  be  contained  within  at  most  one  pipe. 

I 

This  entity  is  also  a  specialized  data  element  for  capturing  data  that  have 
atomic  values,  i.e.,  are  not  pipes.  Attribute,  data  type,  indicates  the  type  of 
data  (in  the  Pascal  or  Ada  sense);  minimum  is  the  minimum  data  value,  if 
applicable,  maximum  is  the  maximum  data  value,  if  applicable,  and  range 
is  the  data  value  range,  if  applicable  (16:14).  In  the  case  that  none  of 
the  attributes  are  applicable,  entity  values,  as  described  below,  probably 
applies. 

i  values 

| 

This  entity  is  used  to  accommodate  atomic  data  items  which  have  enumer¬ 
ated  values,  e.g.,  color  can  have  values  red,  blue,  and  green.  The  entity  has 
a  single  (key)  attribute,  value  (16:14). 

I  can  have 

This  relationship  ties  the  atomic  data  item  entity  to  its  corresponding  values 
entity. 

j  alias 

j 

This  weak  entity,  which  is  existence  dependent  upon  data  element,  cap¬ 
tures  any  aliases  that  the  given  data  element  might  have.  Attribute,  name. 
is  the  name  of  the  alias  and  the  discriminant  of  this  weak  entity  set,  at¬ 
tribute,  comment,  is  used  by  the  analyst  to  clarify  why  the  alias  was  needed, 
and  attribute,  where  used,  indicates  where  the  alias  is  used  (16:14) 

i  has  an 

1 

1 

This  relationship  shows  that  a  data  element  can  have  zero  to  many  aliases, 
and  that  a  given  alias  corresponds  to  exactly  one  data  element. 
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Drawing  Data  Model.  As  discussed  above,  the  drawing  data  model  represents  the  actual 
graphical  constructs,  e.g.,  boxes,  line  segments,  etc.,  used  to  represent  the  particular  IDEFo  anal¬ 
ysis. 

As  with  the  essential  data  model,  the  E-R  analysis  of  the  drawing  data  model  is  done  in  two 
parts  that  complement  one  another.  The  first  part  of  the  analysis  shows  the  activities  and  other 
graphical  constructs,  e  g.,  squiggles,  etc.,  with  the  details  about  data  elements  left  out.  The  second 
part  only  shows  the  data  element  model. 

Figure  16  illustrates  the  drawing  model  associated  with  IDEFo  activities  and  Figure  17  illus¬ 
trates  the  drawing  model  associated  with  IDEFo  data  elements.  Each  of  the  entities  and  relation¬ 
ships  for  both  E-R  diagrams  is  explained  in  Table  2.  As  appropriate,  a  reference  is  given  citing 
why  the  entity,  relationship,  or  attribute  is  needed. 
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Figure  16.  IDEFq  ACTIVITY  Drawing  Data  Model 
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Table  2.  Description  of  Components  in  the  Drawing  Data  Model 


E-R  construct 

description 

box 

This  weak  entity,  which  is  existence  dependent  upon  activity,  captures  the 
graphical  construct  which  represents  an  activity  on  the  IDEFo  diagram.  At¬ 
tributes,  r,  and  y,  indicate  the  location  of  the  upper  left  hand  corner  of  the 
box  (all  boxes  are  the  same  size).  The  attribute,  visible  DRE.  corresponds 
to  Ross's  detail  reference  expression.  In  Ross’s  words  "The  omission  of  a 
detail  reference  expression  indicates  that  the  box  is  not  further  detailed  in 
this  model”  (30:33). 

is  represented  by 

This  relationship  simply  indicates  the  one  to  one  correspondence  between 
an  activity  and  its  graphical  representation,  box. 

activity 

This  entity  is  described  in  the  section  dealing  with  the  essential  data  model. 

sheet 

This  weak  entity,  which  is  existence  dependent  upon  activity,  captures  the 
fact  that  an  activity  is  decomposed.  It  has  the  single  attribute,  c-number 
(24:17).  Note  that  c-number  is  used  as  the  DRE  symbol  on  the  parent 
diagram. 

is  decomposed  on 

This  relationship  ties  an  activity  to  the  sheet  upon  which  it  is  decomposed, 
if  such  a  decomposition  exists. 

drawn  on 

This  relationship  ties  a  box  to  the  sheet  upon  which  it  is  drawn. 

graphics  artifact 

This  weak  entity,  which  is  existence  dependent  upon  sheet  is  a  generalized 
entity  which  includes  note  and  squiggle  (30:20). 

contains 

This  relationship  indicates  that  a  given  sheet  can  contain  zero  to  many 
graphics  artifacts. 

note 

This  entity  is  used  to  capture  the  location  of  note  markers,  and  it  is  the  gen¬ 
eralized  entity  for  both  text  notes  (footnote  and  meta-note)  ,  and  FEO 
(30:20).  There  are  two  attributes,  i,  and  y,  which  indicate  the  location  of 
the  note  marker  on  the  diagram. 

squiggle 

This  entity  simply  contains  the  four  ordered  pairs  which  denote  the  location 
of  a  squiggle  on  the  sheet  (30:20). 

text 

This  entity,  which  is  a  member  of  entity,  note,  as  seen  from  the  ISA  con¬ 
struct,  captures  the  text  for  meta-notes  and  footnotes.  Attribute,  contents. 
holds  the  text  of  the  note  and  the  ISA  construct  indicates  the  type  of  note, 
i.e.,  footnote  or  meta-note  (30:20). 

|  FEO 

This  entity,  which  is  a  member  of  entity,  note,  as  seen  from  the  ISA  con¬ 
struct,  captures  the  drawings  associated  with  the  for  exposition  only  (FEO) 
(30:22). 

footnote 

This  entity  is  a  specialized  type  of  text  note  as  seen  from  the  ISA  construct. 
Attributes  z,  and  y,  are  the  location  on  the  drawing  where  the  footnote  is 
placed. 

meta-note 

This  entity  is  a  specialized  type  of  text  note  as  seen  from  the  ISA  construct 
on  the  E-R  diagram. 

label 

This  weak  entity,  which  is  existence  dependent  upon  data  element,  cap¬ 
tures  the  label  associated  with  a  data  element,  as  well  as  the  location  of 
the  label  on  the  diagram.  Discriminant  attribute,  label,  is  the  label  itself, 
and  attributes,  r.  and  y.  are  the  location  of  the  first  character  of  the  label 
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Table  2  (continued):  Description  of  Components  in  the  Drawing  Data  Model 


E-R  construct 

description 

corresponds  to 

This  relationship  connects  a  data  element  to  it's  label.  A  data  element 
can  have  zero  to  many  labels,  but  a  given  label  can  only  refer  to  one  data 
element. 

data  element 

This  entity  is  described  in  the  section  dealing  with  the  essential  data  model. 

line  segment 

This  weak  entity,  which  is  existence  dependent  upon  data  element,  cap¬ 
tures  all  the  line  segments  from  which  the  graphical  representation  of  a 
data  element  is  built. 

is  built  from 

This  relationship  simply  indicates  that  a  data  element  is  graphically  repre¬ 
sented  by  at  least  one  but  perhaps  many  line  segments. 

is  drawn  on 

This  relationship  indicates  the  sheet  on  which  a  particular  line  segment  is 
drawn.  It  also  indicates  that  a  sheet  can  have  one  to  many  line  segments 
drawn  on  it. 

symbol 

This  weak  entity,  which  is  existence  dependent  upon  line  segment,  is  a 
generalized  entity  used  to  capture  the  type  of  symbol  with  which  a  line 
segment  either  starts  or  ends. 

starts  with 

This  relationship  connects  a  line  segment  to  the  symbol  with  which  the 
line  segment  starts.  The  two  attributes,  r,  and  y,  are  the  location  of  the 
starting  symbol.  Note  that  a  line  segment  can  start  with  more  than  one 
symbol,  e  g.,  an  arrow  and  a  dot. 

ends  with 

This  relationship  connects  a  line  segment  to  the  symbol  with  which  the  line 
segment  ends.  The  two  attributes,  r,  and  y,  are  the  location  of  the  ending 
symbol.  Note  that  a  line  segment  can  end  with  more  than  one  symbol,  e  g., 
icom  code  (boundary)  and  arrow. 

boundary 

This  entity  indicates  that  the  starting  or  ending  symbol  on  the  line  segment 
corresponds  to  a  boundary.  Attribute,  type,  indicates  the  type  of  boundary 
(Input,  Control,  Output,  and  Mechanism),  and  attribute,  number,  is  the 
number  of  the  boundary  (24:22). 

all 

_ 

This  entity  captures  the  to-all  and  from-all  construct:  the  single  attribute, 
label,  captures  the  to-all/from-all  label  (30:31-32). 

tunnel 

! 

This  entity  denotes  that  the  line  segment  corresponds  to  a  tunnel  arrow;  the 
attribute,  type,  indicates  if  this  is  an  external  arrow  that  did  not  appear 
on  the  parent  diagram  (hidden  source),  or  if  it  is  an  arrow  that  touches 
an  activity  but  does  not  appear  on  that  activity's  decomposition  (hidden 
destination)  (24:24). 

j  turn 

This  entity  is  used  if  the  line  segment  starts  or  ends  with  a  turn.  Attribute. 
type,  determines  the  type  of  turn  (right-up,  left-up,  right-down,  left-down, 
up-right,  up-left,  down-right,  and  down-left). 

arrow 

This  entity  is  used  if  the  line  segment  starts  or  ends  with  an  arrow.  At¬ 
tribute  type  determines  the  type  of  arrow  (right,  left,  up.  and  down). 

dot 

This  entity  is  used  in  the  case  of  two-way  arrows  (30:20). 

|  null 

l 

i 

1 _ 

This  entity  is  used  if  the  line  segment  does  not  have  a  starting  or  ending 
symbol,  e  g.,  the  segment  simply  connects  to  another  segment  and  therefore 
does  not  have  a  starting  symbol. 
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[DEFci  Relational  Database 


This  section  considers  some  of  the  design  trade-offs  associated  with  the  relational  implemen¬ 
tation  of  the  IDEFo  database;  the  mapping  of  the  E-R  model  into  relations;  an  example  database 
for  the  relational  design;  the  Ingres  implementation  of  this  design;  and  SQL  queries  which  extract 
data  from  the  Ingres  implementation. 

Design  Trade  Offs.  In  coming  up  with  the  relational  design,  several  trade  offs  are  considered. 
With  one  exception,  the  relational  design  retains  the  explicit  division  between  the  essential  data 
and  drawing  data.  The  exception  is  the  relation,  activity,  which  includes  both  essential  data,  and 
drawing  data.  The  justification  is  simple.  Fully  separating  the  activity  from  its  box  representation 
results  in  either;  a  significant  amount  of  replicated  data,  e  g.,  name  (essential),  name  (drawing), 
node  (essential),  node  (drawing),  etc.;  or  requires  all  queries  associated  with  retrieving  box  data  to 
involve  joins,  which  are  costly.  In  short,  the  drawing  data  abstraction,  box,  and  its  essential  data 
abstraction,  activity,  are  both  contained  in  the  same  relation. 

In  the  interest  of  efficient  queries,  seemingly  redundant  "id"  attributes  are  added  to  certain 
relations.  For  example,  the  attribute,  project.id,  in  relation,  project,  is  redundant  since  the  at¬ 
tribute  name  is  a  superkey.  However,  a  query  involving  a  4-byte  integer  project.id  is  intuitively 
more  efficient  (time  wise)  than  a  query  involving  a  12  byte  character  string. 

All  the  relations  corresponding  to  weak  entities  have  a  globally  unique  “id”  attribute  which 
eliminates  the  need  for  extraction  of  superkeys  from  the  relation  on  which  the  given  weak  entity  is 
existence  dependent.  This  is  done  in  the  interest  of  of  efficiency  (relative  to  queries).  An  example 
is  the  attribute,  node. id,  in  the  activity  relation.  Obviously  the  “real”  superkey  for  activity  is 
the  attribute  pair,  node,  project-name.  Once  again,  a  4-byte  integer  comparison  is  more  efficient. 

Several  of  the  drawing  data  relations  have  the  sheet.id  attribute  included  in  them,  whereas 
the  E-R  diagrams  show  no  such  direct  relationship.  This  is  done  to  eliminate  the  need  for  multiple 
joins.  A  good  example  is  the  arrow  relation.  Obviously,  a  join  between  arrow,  symbol,  segment, 
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and  sheet  is  needed  to  determine  which  arrows  go  on  which  sheets.  By  simply  adding  the  sheet. id 
into  the  arrow  relation,  the  joins  are  eliminated.  Clearly  this  generates  additional  problems  relative 
to  redundancy  and  consistency.  However,  it  is  felt  that  the  sheet.id  attribute  is  not  like  to  change 
frequently,  whereas  queries  to  draw  the  diagrams  will  occur  frequently.  In  short,  the  decision,  while 
increasing  redundancy  and  creating  an  increased  potential  for  inconsistent  data,  provides  a  more 
efficient  implementation  (time  wise). 

Finally,  some  of  the  entities  and  relationships  were  collapsed  into  a  single  relation;  some  were 
renamed  to  make  their  roles  more  clear  This  section  includes  tables  which  show  the  connection 
between  the  requirement  (as  manifested  in  the  E-R  analysis)  and  the  implementation  (as  manifested 
m  the  relational  design). 

Relational  Design.  In  developing  the  relational  design,  the  approach  taken  was  to  initially 
do  a  straight  one-to-one  translation  from  the  E-R  diagrams,  and  then  through  stepwise  refinement, 
reduce  the  tables  as  alluded  to  above.  In  fact,  it  took  21  iterations  to  get  the  relations  into  the 
format  shown  in  Table  3.  The  bold  faced  header  indicates  the  name  of  the  relation  and  a  brief 
description  of  the  relation.  This  header  is  followed  by  a  three  column  layout  which  shows  the  name 
of  each  attribute,  its  type  (e.g.,  integer4),  and  a  brief  description  of  the  attribute. 
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_ _ Table  3.  Relational  Design _ 

act2act  cross  reference  parent  activity  to  its  child  activities 

parent. node  i4  identifies  the  parent  activity 

child-node  14  identifies  the  child  activity 

act2data  cross  reference  activity  to  its  data  elements 

nodeJd  i4  identifies  the  activity 

datajd  i4  identifies  the  data  element 

icom.type  cl  I=input,  C=control,  0=output,  \l=mechanism 

act2hist  cross  reference  activity  to  historical  activity  being  called 


node.id 

i4  identifies  the  calling  activity 

hist.id 

i4  identifies  called  historical  project/activity 

act2ref 

cross  reference  activity  to  it  references 

node.id 

i4  identifies  the  activity 

ref-id 

i4  identifies  the  reference 

activity 

IDEFq  activity  or  its  box  representation 

node.id  i4  key  attribute  identifies  activity 

node  c20  node  number  for  activity 

name  c25  name  of  activity 

project-id  i4  identifies  the  project 

author.id  i2  identifies  the  analyst 

version  clO  activity  version 

date  c8  date  this  version  was  created 

x  i2  x-wise  location  of  box  representation 

y  i2  y-wise  location  of  box  representation 

visibleJDRE  il  -1  =  activity  is  decomposed,  n  -  not  yet 

sheet-id  i4  sheet  on  which  this  activity  appears 


act  .changes 

changes  made  to  the  activity 

node-id 

changes 

i4 

c60 

identifies  the  activity 
description  of  the  change 

act.descr  descriptions  can  be  multiple  lines 
node.id  i4  identifies  the  activity 

line.no  i2  keep  description  lines  in  proper  order 

desc.line  c60  one  line  of  the  description 


Table  3  (continued):  Relational  Database  Design 


alias 

data  element  can  have  multiple  aliases 

dataJd 

i4 

identifies  the  data  element 

name 

c25 

name  of  alias 

where. used 

c25 

where  alias  is  used 

comment 

c25 

why  alias  is  needed 

analyst 

person  doing  the  analysis 

author.id 

i2 

key  attribute  identifies  analyst 

author 

c20 

name  of  analyst 

arrow 

type  of  arrow 

symbolJd 

i4 

key  attribute  identifies  arrow 

arrow. type 

n 

0  =  up,  1  ss  down,  2  =  left,  3  =  right 

boundary 

ICOM  codes  for  boundary  arrows 

symbolJd 

i4 

key  attribute  identifies  boundary  symbol 

icom.code 

c2 

l,  C,  0,  M  {input,  control,  output,  mechanism) 

data2data 

cross 

reference  pipe  data  element  to  its  children 

parent.data 

i4 

identifies  the  parent  data  element 

child-data 

i4 

identifies  the  child  data  element 

data21abel 

cross 

reference  data  element  to  its  labels 

dataJd 

i4 

identifies  the  data  element 

label-id 

i4 

identifies  the  label 

data2ref 

cross 

reference  data  element  to  its  references 

data-id 

El 

identifies  the  data  element 

refJd 

El 

identifies  the  reference 

data2value 

cross 

reference  data  element  to  its  data  type  values 

data_id 

El 

identifies  the  data  element 

valuejd 

n 

identifies  the  data  type  value 

data.changes 

changes  to  the  data  elements 

dataJd 

i4 

identifies  the  data  element 

changes 

c60 

description  of  the  change 

data.descr 

descriptions  can  be  multiple  lines 

dataJd 

El 

identifies  the  data  element 

line.no 

B 

keep  description  lines  in  proper  order 

desc.line 

[gill 

one  line  of  the  description 

datajelem 

IDE1 

"o  data  element 

dataJd 

El 

key  attribute  identifies  the  data  element 

name 

name  of  data  element 

project-id 

m 

identifies  the  project 

author.id 

i2 

identifies  the  analyst 

version 

clO 

data  element  version 

date 

c8 

date  this  version  was  created 
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Table  3  (continued):  Relational  Database  Design 


data_range 


dataJd 

data_range 


datatype 


dataJd 

type 


data.value 


^p™ppbBhB|[ 


range  of  this  atomic  data  element 


i4  key  attribute  identifies  the  data  element 
c60  range  of  legal  values 


data  type  of  this  atomic  data  element 


footnote 


grafJd 


graphics 


grafJd 
sheet. id 


hist. call 


hist-id 

hist.proj 

hist_node 


label 


label-id 


y 

sheet-id 


i4  key  attribute  identifies  the  data  element 
c25  data  type 


legal  values  for  enumerated  atomic  data  elements 


key  attribute  identifies  the  value 
the  actual  value 


type  of  dot  (Ross’s  two-way  arrow  notation) 


key  attribute  identifies  dot 
0  =  above-right,  1  =  below-right,  3  =  below-left 


location  of  actual  footnote  text 


key  attribute  identifies  the  footnote 
x-wise  location  of  actual  text 
y-wise  location  of  actual  text 


for  exposition  only  (picture) 


i4  key  attribute  identifies  the  FEO 
c60  perhaps  the  name  of  a  graphics  file? 


graphics  artifacts 


key  attribute  identifies  graphic  artifact 
identifies  sheet  on  which  graphic  is  drawn 


historical  activity  call 


key  attribute 

name  of  project  containing  the  historical  activity 
node  number  within  the  project,  e  g..  A312 


label  associated  with  a  data  element 


key  attribute  identifies  the  label 
name  of  the  label 
x-wise  location  of  the  label 
y-wise  location  of  the  label 
identifies  sheet  where  label  is  drawn 


minimum  and  maximum  values  for  atomic  data  elements 


HI 

nui 

I 


key  attribute  identifies  data  element 
minimum  value 
maximum  value 
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Table  3  (continued):  Relational  Database  Design 


note 

some 

kind  of  note 

graf.id 

i4 

key  attribute  identifies  the  note 

label 

cl 

the  label  associated  with  the  marker 

X 

E| 

x-wise  location  of  the  marker 

y 

H 

y-wise  location  of  the  marker 

note-text 

contents  of  a  note  can  be  multiple  lines 

graf.id 

jm 

key  attribute  identifies  note  contents 

line.no 

keep  contents  lines  in  proper  order 

text.line 

one  line  of  text  for  the  note 

project 

project  (model)  name 

project. id 

i4 

key  attribute  identifies  project  (model) 

name 

c  1 2 

project  name 

reference 

references  can  be  multiple  lines 

ref.id 

E ■ 

key  attribute  identifies  the  reference 

line.no 

keep  reference  lines  in  proper  order 

ref.line 

a  line  of  this  reference 

ref_type 

type  of  reference 

El 

key  attribute  identifies  the  reference 

type  of  reference 

segment 

line  segments  graphically  representing  a  data  element 

seg.id 

key  attribute  identifies  the  line  segment 

data.id 

data  element  for  this  segment 

sheet.id 

sheet  where  the  segment  is  drawn 

xs 

x-wise  point  where  line  segment  starts 

ys 

y-wise  point  where  line  segment  starts 

xe 

i2 

x-wise  point  where  line  segment  ends 

ye 

i2 

y-wise  point  where  line  segment  ends 

sheet 

sheet  containing  activity 

sheet.id 

i4 

key  attribute  identifies  the  sheet 

c.number 

i4 

Ross’s  c-number 

squiggle 

Ross’s  famous  squiggle 

graf.id 

mu 

key  attribute  identifies  the  squiggle 

xl 

m 

location  of  the  four  points 

yi 

m 

which  connect  in  the  order 

x2 

\2 

1  —  2  —  3  —  4 

y2 

i2 

to  make  the  squiggle 

x3 

i2 

y3 

i2 

x4 

i2 

y4 

i2 
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Table  3  (continued):  Relational  Database  Design 


symbol 

segments  start  and  end  with  many  kinds  of  symbols 

symbol  Jd 

14 

key  attribute  identifies  the  symbol 

seg.id 

i4 

identifies  the  segment  associated  with  this  symbol 

sheet. id 

i4 

identifies  sheet  on  which  the  symbol  is  drawn 

X 

i2 

x-wise  location  of  symbol 

V 

i2 

y-wise  location  of  symbol 

to  _from-all 

label  for  to-all  and  from-all  arrows 

symbol-id 

D 

key  attribute  identifies  the  symbol 

tfaJabel 

D 

label  in  the  to-all  from-all  circle 

tunnel 

Ross's  famous  disappearing  arrows 

symbol-id 

i4 

key  attribute  identifies  the  symbol 

tunnel.type 

il 

—  1  =  hidden  source,  0  =  hidden  destination 

turn 

type  of  turn,  combos  of  up,  down,  right,  and  left 

symbol  Jd 

i4 

key  attribute  identifies  the  symbol 

turn.type 

il 

0=ru,  l=lu,  2=rd,  3=ld,  4=ur,  5=ul,  6=dr,  7=dl 

Essential  Data  Requirements  to  Design  Connection.  Table  4  shows  the  connection  be¬ 
tween  the  essential  data  requirements  (as  manifested  in  the  E-R  analysis)  and  the  implementation 
(as  manifested  in  the  relational  design).  The  notation  entity. attribute,  and  relation. attribute  is 
used  to  denote  a  particular  attribute  for  a  given  entity  or  relation. 


Drawing  Data  Requirements  to  Design  Connection  Table  5  shows  the  connection  be¬ 
tween  the  drawing  data  requirements  (as  manifested  in  the  E-R  analysis)  and  the  implementa¬ 
tion  (as  manifested  in  the  relational  design).  As  before,  the  notation  entity  attribute,  and  rela¬ 
tion.  attribute  is  used  to  denote  a  particular  attribute  for  a  given  entity  or  relation. 

Example  Relational  Database  Instance.  An  example  database  corresponding  to  the  diagrams 
shown  in  Figure  7  and  Figure  8  was  constructed  by  hand.  Appendix  F  has  a  listing  of  the  example 

database 

Relational  Implementation.  The  relational  design  shown  in  Table  3  is  implemented  within 
Ingres  Corporation’s  relational  DBMS,  Ingres.  The  script  file  used  to  create  the  relations  is  shown 
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Table  4.  Mapping  of  E-R  Essential  Data  to  Relational  Design 


E-R  construct 

Relational  Design  Construct 

activity 

activity 

activity .  descript  ion 

act.descr 

composed  of 

act2act 

analyst 

analyst 

analyzes 

activity .  author. id 
data  _elem.  author,  id 

analyst,  version 

activity  version 
data.elem.  version 

analyst,  dale 

activity. date 
data_elem.  date 

analyzes  changes 

act -changes 
data.changes 

project 

project 

part  of 

activity  project. id 
data.elem.  project,  id. 

ref 

reference 

ref.type 

based  on 

act2ref 

data2ref 

historical  activity 

hist -call 

.. 

calls 

act2hist 

inputs 
outputs 
is  controlled  by 
is  mechanized  by 

act2data 

data  element 

data-elem 

data  element. description 

data_descr 

pipe 

consists  of 

data2data 

atomic  data  item. data  type 

data_type 

atomic  data  item,  minimum 
atomic  data  item. maximum 

min_max 

atomic  data  item. range 

data_range 

values 

data.value 

can  have 

data2value 

alias 

alias 

has  an 

alias,  data,  id 
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Table  5.  Mapping  of  E-R  Drawing  Data  to  Relational  Design 


E-R  construct 

Relational  Design  Construct 

box 

activity  r 

is  represented  by 

activity  .1 
activity,  y 

activity.  vtsible.DRE 

sheet 

sheet 

is  decomposed  on 

To  find  the  sheet  on  which  an  activity 
is  decomposed,  one  must  look  at  activ¬ 
ity.  sheet-id  of  any  child  of  the  activity 
(via  act2act) 

drawn  on 

activity,  sheet,  id 

graphics  artifact 

graphics 

contains 

graphics,  sheet-id 

note 

note 

squiggle 

squiggle 

text 

note -text 

FEO 

FEO 

footnote 

footnote 

meta-note 

A  note  tuple  which  does  not  have  a  corre¬ 
sponding  footnote  tuple  is  a  meta-note. 

label 

label 

corresponds  to 

data21abel 

line  segment 
is  built  from 
is  drawn  on 

segment 

symbol 
starts  with 
ends  with 

symbol 

boundary 

boundary 

all 

to-from_all 

tunnel 

tunnel 

j  turn 

turn 

arrow 

arrow 

dot 

dot 

null 

A  line  segment  end  for  which  there  is  not 
a  symbol  simply  does  not  have  an  entry 
in  any  of  the  available  symbol  relations, 
e  g.,  arrow,  etc. 
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m  Appendix  G,  as  are  the  script  files  used  to  input  the  hulk  data  files,  show  the  contents  of  all  the 
tables,  and  delete  all  data  from  the  database.  The  next  section  shows  some  queries  used  to  extract 
the  drawing  data  from  this  example  database. 

SQL  Queries.  Although  this  thesis  effort  does  not  involve  building  a  tool  to  actually  draw  an 
IDFF  j  diagram,  such  a  tool  might  require  the  user  to  supply  the  name  of  the  project.  Accordingly, 
the  queries  shown  below  have  "DM  Example’’  as  the  project  name. 

The  first  query  extracts  the  data  required  to  begin  drawing  the  A-0  diagram  illustrated  in 
Figure  7.  The  table  immediately  following  the  query  contains  the  tuples  that  are  extracted  as  a 
result  of  the  query  Note  that  Ingres  truncates  the  column  title  to  be  commensurate  with  the  data 
'ize.  e  g.,  visible JDRE  is  of  type  integer  1.  so  the  column  title  gets  truncated  to  visibl. 


select  a  x . y , a . name , a  data ,an . author ,a . version ,a . visibls.DRE , s .  c.numbvr 
from  activity  a.  analyst  an,  sheet  s 
where  a. node  a  "10"  and 
a  author.id  «  an. author _id  and 
s  sheet.id  a  a. sheet. id  and 
a  project.id  in  ( 
select  p  project.id 
from  project  p 

where  p  name  »  "DM  Example"); 

l<  ly  Iname  Idate  I  author  Iversion  I visibl I c.number  I 

I . - . . . - . - . . 1 

I  ll  llmanage  database  1 02/14/891  Gerald  R.  Morris  1 1.0  I  -ll  II 


At  this  point,  a  drawing  tool  can  draw  the  blank  sheet,  and  fill  in  NODE  (A-0),  NUMBER 
( always  a  1  for  A-0).  PROJECT  (DM  Example),  TITLE  (same  as  PROJECT  for  A-0  sheet).  DATE. 
VI  IHOR.  and  REV  (version)  on  the  sheet  The  tool  can  draw  the  box  at  location  (x,y)2.  fill  in 
th>'  name  of  the  activity,  and  enter  the  node  number  in  the  activity  box3.  Finally,  if  visible. DRE  is 
tru>'  (-1).  the  tool  can  put  the  c.number  to  the  lower  right  of  the  activity  box  to  denote  the  sheet 

*  [  he  (x.y)  values  are  only  symbolic  in  this  example,  normally  they  represent  a  location  on  the  screen 
In  the  specific  case  of  the  AO  node,  the  node  number  is  a  1,  not  the  expected  0,  shame  on  you  Douglas  Ross! 
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AUTHOR.  Gerald  R  Morns 

DATE  UFebSS 

READER 

— 

PROJECT  DM  Example 

REV  1  0 

DATE 

— 

manage 

database 


NODE 

A-0 


TITLE  DM  Example 


NUMBER  I 


Figure  18.  A-0  Diagram  (partial  drawing  1) 

on  which  it  is  decomposed  (Ross's  detailed  reference  expression).  The  partial  drawing  that  results 
is  shown  in  Figure  18. 


This  next  query  extracts  all  the  line  segments  which  represent  the  data  arrows  on  the  A-0 
As  before,  the  table  immediately  following  the  query  contains  the  tuples  that  are  extracted 
<s  a  result  of  the  query. 
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Figure  19.  A-0  Diagram  (partial  drawing  2) 


select  se  xs , se  ys  ,se . xe , se  ye 
from  segment  se 
where  se  sheet_id  in  ( 
select  a.sheet_id 
from  project  p, activity  a 
where  p . pro ject .id  *  a.project.id  and 
a  node  *  "AO"  and 
p  name  *  "DM  Example"); 


1  xs 

ly* 

li« 

lT« 

31 

31 

41 

4 

61 

61 

71 

7 

91 

91 

101 

10 

Notice  that  for  each  line  segment,  there  are  two  (x.y)  pairs.  These  points  represent  the  end 
'I  the  line  segments  which  are  drawn  by  the  drawing  tool.  The  updated  partial  drawing  that  result 
IV'mii  adding  the  line  segments  is  shown  in  Figure  19. 
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The  queries  required  to  complete  t he  A-0  drawing  are  shown  in  Appendix  G.  as  are  the  queries 
needed  to  draw  the  AO  diagram.  In  addition.  Appendix  G  contains  example  SQL  queries  to  extract 
•  •"-eutial  activity  data  and  essential  data  element  data  from  the  Ingres  implementation  These 
queries  provide  tin-  data  necessary  to  create  the  data  dictionary  examples  shown  in  Appendix 

IDEFi)  Sested  Relational  Database 

This  section  considers  some  of  the  design  trade-offs  associated  with  the  nested-relational 
version  of  the  IDEFq  database;  the  mapping  of  the  relational  design  into  a  nested-relational  design: 
an  example  database  for  the  nested-relational  design;  a  “paper"  implementation  of  this  design:  and 
SQL/NF  queries  which  extract  data  from  the  nested-relational  implementation. 

Design  Trade-Offs  Because  the  nested-relational  model  is  an  extension  of  C’odd's  relational 
model,  the  relational  design  is  used  as  the  starting  point.  In  this  nested-relational  design,  the 
drawing  data  and  essential  data  are  completely  separated. 

As  with  the  relational  design,  certain  "id”  attributes  are  retained  in  the  interest  of  efficient 
queries,  e  g.,  a  d-byte  integer  comparison  versus  a  12-byte  character  string  comparison 

There  is  some  redundancy  in  this  database,  e  g.,  some  of  the  data  in  the  activities  relation- 
vi ilued  attribute  are  also  found  in  the  sheets  relation-valued  attribute.  The  decision  to  ■  lo  this 
is  based  on  the  cost  of  joins  versus  the  cost  of  redundancy  Joins  between  nested  relation-valued 
attributes  can  involve  unnesting  the  involved  relation-valued  attributes,  doing  the  join,  and  then 
nesting  again  This  is  an  intuitively  expensive  operation.  It  is  felt  that  the  cost  of  redundancy 
m"i<'  than  offsets  the  cost  of  doing  a  join  on  the  nested  attributes. 

Several  other  design  trade-offs  are  considered  during  the  development  of  this  nested-relational 
version  In  particular;  whether  to  nest  data  elements  inside  of  activities,  activities  inside  of  data 
elements,  or  neither;  whether  to  nest  data  elements  inside  data  elements  (recursively),  and  whether 
to  recursively  nest  activities  inside  activities. 
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From  a  purely  graphical  viewpoint,  the  seemingly  "natural”  approach  is  to  nest  data  elements 
inside  of  activities  since  a  given  activity's  decomposition  "contains”  data  elements.  However,  this 
■  (uicklv  leads  to  trouble  since  a  given  data  element  is  an  input,  output,  control,  or  mechanism, 
perhaps  a  combination  of  several  depending  upon  how  many  activities  it  touches.  The  implication 
of  nesting  data  elements  inside  activities  is  that  each  activity  which  uses  the  data  element  has 
to  nest  the  identical  data  in  its  attributes.  This  immediately  leads  to  a  potentially  high  degree 
of  duplication.  Thus  there  is  again  the  dilemma  of  redundancy  due  to  increased  nesting  versus 
increased  requirements  for  joins  due  to  a  more  flattened  design.  In  a  pathalogical  case,  a  given  data 
element  might  touch  dozens  of  activities.  Of  course  the  biggest  problem  is  that  the  essential  data 
model  does  not  keep  track  of  tunnel  arrows  (a  strictly  graphical  construct  designed  to  minimize 
unnecessary  clutter  on  a  diagram).  This  means  a  given  data  element  could  "appear”  suddenly  as 
an  input  (for  example)  to  an  activity  without  having  traversed  the  parent  activity.  In  short,  an 
update  to  a  single  data  element  requires  an  enumeration  of  all  activities.  Another  problem  that 
results  from  nesting  data  elements  inside  activities  is  that  of  deletion.  If  an  activity  is  deleted,  are 
all  of  its  data  elements  also  deleted?  The  issues  described  above  relate  to  the  partial  dependency 
problem  found  in  the  flat  relational  model.  A  full  discussion  is  beyond  the  scope  of  this  thesis  but 
Ozsoyoglu  and  Yuan  address  this  problem  within  the  context  of  nested-normal  form  (26).  At  any 
rate,  the  decision  is  to  not  nest  data  elements  inside  activities,  to  simply  put  a  list  of  data  element 
names  and  icom  types  inside  each  activity. 

The  next  decision  is  whether  or  not  to  nest  activities  inside  one  another  and  whether  or 
not  to  nest  data  elements  inside  one  another.  A  fully  nested  approach  in  either  case  exhibits 
auomolous  behavior  relative  to  "when  to  stop”  whenever  queries  are  done  because  the  algebra 
(query  language)  does  not  support  recursion  and  transitive  closure  Perhaps  this  is  best  illustrated 
by  way  of  a  simple  example  involving  activities  (a  similar  example  can  easily  be  constructed  for 
data  elements)  Suppose  that  activities  are  recursively  nested  inside  one  another  via  relation-valued 
attribute,  child.  Further  suppose  a  query  is  issued  requesting  all  the  offspring  of  the  AO  node  (in 
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flattened  form)  and  that  there  are  only  three  levels  of  nesting.  A  nested-relational  algebra  *|u<‘ry 
looks  something  like 


t(  node,  name(<T«(/j(child(^i(child(  activity ))))))) 

where  t  is  the  database  projection  operation,  a  is  the  selection  operator,  &  is  a  predicate  identifying 
the  appropriate  project.,  and  ^  is  the  unnest  operator  (32)  (8).  The  problem  of  course,  m  the  general 
case,  is  that  the  number  of  levels  of  nesting  associated  with  a  particular  node  is  not  known  apriori; 
thus,  it  is  not  known  how  to  construct  the  query.  On  the  other  hand,  a  similar  query  for  a  design 
in  which  the  activities  are  not  nested  inside  one  another  could  be  expressed  as 

tr(node,name(<rj  (activity)) 

where  0  is  a  conjunctive  predicate  identifying  the  project  and  selecting  all  nodes  starting  with  the 
-equence  "AO”.4  Thus,  the  decision  is  to  keep  activities  at  the  same  nesting  level:  the  children  are 
identified  via  a  list  of  node  names  within  each  activity.  For  similar  reasons,  all  data  elements  are 
kept  at  the  same  nesting  level;  children  are  identified  via  a  list  of  data  element  names. 

.Vested- Relational  Design.  The  IDEFo  nested-relational  schema  consists  of  a  single  table, 
project.  Unfortunately,  the  size  of  the  project  schema  precludes  the  use  of  diagrams  like  those 
used  bv  Roth  (33:100),  Colby  (8:5),  and  others.  Thus,  in  order  to  make  the  discussion  of  the 
scheme  comprehensible,  a  hierarchical  approach  is  necessary.  Table  6  is  a  thumb-nail  sketch  of 
the  hierarchical  structure  of  the  nested-relational  design.  To  allow  for  an  easier  to  comprehend 
i '•presentation  a  vertical  presentation  method  is  used. 


4  Hecall  the  syntax  of  IDEFo  requires  offspring  nodes  to  start  with  the  parent  node  number,  eg.  A221  is  t lie  first 
child  of  A22  and  the  second  grandchild  of  A2.  Thus  we  can  take  advantage  of  the  node  number  irlationships  to 
del  ermine  hierarchical  relationships. 
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I 


(aliaaes) 

1  nan*  1 

| - 

1  whare.usad 

1  comment 

(min. max) 

1 data.type 
| - 

1  minimus 

1  max imua 

(ranga) 

1  data. type 
| - - - - 

1 ranga 

i 

(values) 

1  data. type 
| _ 

1  value 

1 

(activiteea) 

lnode.na»e 

1 . 

licom.typa  | 

(children) 

I  data. nans  I 
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(sheets) 

I c.nunbarlnoda  Inane  I  author  leersion  Idate  I 

I -I - 1 - 1 . 1 . - . I . . I 

(boxes) 

Inode  Inane  |x  ly  I  visible. DRE  I 

I . I . - . I-I--I . -I 

(segments) 

I  data. id  I 


(location) 

Ixs  lys  Ixe  lye  I 


(symbols) 

|x  |y  I  type. symbol  I  symbol. type  I 

I  — I  — I - 1 . - . I 

(squiggles) 

Ixl  lyl  1x2  Iy2  1x3  Iy3  1x4  I y4  I 

I - 1 - 1 - 1 - 1 - 1- - I - 1 - 1 

(raeta.notes) 

I  label  lx  ly  I 


(note. text) 

lline.no  I  text .line  I 

I . I . . . "I 

(foot.notes) 

I  label  I xn  I ym  I xn  I yn  I 


(note. text) 

lline.no  I  text. line  I 


(feos) 

I  label  lx  ly  I  picture  I 

I . I 1 - 1- . I 

(labels) 

Idata.id  Inane  lx  ly  I 

I . I . I 1  — I 


From  the  design  sketch  it  is  clear  that,  at  a  nesting  level  of  0.  t he  project  nested-relation 
scheme  consists  of  four  attributes  as  shown  below.  Relation-valued  attributes  (RVA)  are  indicated 
in  bold  type,  atomic-valued  attributes  (AVA)  are  indicated  in  italicized  type. 

1  project.name  -  the  name  of  the  project 

2.  activities  -  all  the  activities  associated  with  this  project;  this  RVA  captures  essential  activity 
data  only 

3.  datajelements  -  all  the  data  elements  associated  with  this  project;  this  RVA  captures  es¬ 
sential  data  element  data  only 

4.  sheets  -  the  drawing  data  for  the  project;  this  RVA  captures  both  the  activity  drawing  data 


and  the  data  element  drawing  data 


The  discussion  that  follows  considers  each  of  the  three  RVA,  and  their  associated  AVA/RYA 


At  a  nesting  level  of  1,  the  activities  RVA  scheme  consists  of  fourteen  attributes  as  listed 
below  As  before.  RVA  are  indicated  in  bold  type,  AVA  are  indicated  in  itahct:ed  type. 

1.  node. id5  -  identifies  the  activity 

2.  node  -  node  number,  e  g.,  A32 

3.  name  -  name  of  the  activity 

4.  author  -  name  of  the  analyst 

5.  version  -  revision  number 

6.  date  -  date  of  this  revision 

7.  changes  -  changes  for  this  revision 

8.  c -number  -  sheet  on  which  this  activity  is  drawn 

9.  parent  -  name  of  the  parent  activity 

10.  act.descr  -  description  of  the  activity 

11.  refrences  -  why  the  activity  is  needed 

12.  hist.calls  -  calls  to  activities  from  other  previously  completed  projects 

13.  data.elems  -  data  elements  associated  with  this  activity 
14  children  -  child  nodes  of  this  activity 

The  discussion  that  follows  describes  the  RVA  associated  with  the  activities  RVA  At  a 
nesting  level  of  2,  the  act.descr  RVA  has  2  atomic  attributes;  hne.no  (helps  ensure  the  description 
lines  are  retrieved  in  the  proper  order);  and  desc.hne  (one  line  in  the  description). 

'The  integer  valued  node-id  is  used  in  lieu  of  node  for  reasons  of  efficiency,  i.e.,  it's  faster  to  compare  a  4-bytc 
integer  than  a  string. 
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At  a  nesting  level  of  2,  refrences  consists  of  two  attributes;  refjype  (the  type  of  reference, 
e.g  .  MILSTD),  and  the  relation-valued  attribute  refJines  (contains  lines  of  text  elucidating  the 
reference). 

RVA  refJines.  at  a  nesting  level  of  3,  has  the  two  attributes  ltne.no ;  and  ref. line.  The  former 
is  a  number  to  help  keep  the  latter  lines  of  text  in  the  proper  order. 

At  a  nesting  level  of  2,  the  hist. calls  RVA,  which  has  the  two  attributes  hist.proj  and  hist  .act. 
captures  the  project  name  and  node  (activity)  which  is  being  called. 

The  data.elems  RVA  (also  at  a  nesting  level  of  2)  has  two  attributes,  dain.name  and 
icom.tijpe  which  specify  the  data  element  and  its  role  (input,  control,  output,  mechanism)  with 
respect  to  the  particular  activity. 

Finally,  at  a  nesting  level  of  2  is  the  children  RVA  with  a  single  attribute  node. name.  This 
is  a  list  of  all  children  of  the  activity6. 

The  next  RVA  considered  is  again  at  a  nesting  level  of  1.  The  data_elements  RVA  scheme 
consists  of  fourteen  attributes  as  enumerated  below. 

1.  data.id ‘  -  identifies  the  data  element 

2.  name  -  the  name  of  the  data  element 

3.  author  -  name  of  the  person  who  did  the  analysis 

-1  version  -  the  current  version  number 

5  dale  -  date  of  the  revision 

b.  changes  -  changes  reflected  in  this  version 

7  parent  -  name  of  the  parent  data  element 

''Strictly  speaking,  this  is  not  necessary  since  a  child  node  can  always  be  found  by  looking  at  the  node  number, 
nonetheless  it  is  included  in  the  interest  of  efficiency. 

The  integer  valued  datajd  is  used  in  lieu  of  name  for  reasons  of  efficiency,  i.e.,  it  s  faster  to  compare  a  4-byte 
integer  than  a  string. 
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■S.  data.descr  -  a  description  of  this  data  dement 


9.  refrences  -  why  the  data  element  is  needed 

10.  aliases  -  aliases  for  this  data  element 

11.  min-inax  -  minimum  and  maximum  values  for  atomic  data  elements 

12.  range  -  range  of  values  for  atomic  data  elements 

13.  values  -  list  of  values  for  enumerated  atomic  data  elements 

14.  activitees  -  activities  touched  by  the  data  element 

15.  children  -  children  of  pipe  data  elements 

The  discussion  that,  follows  describes  the  RVA  associated  with  the  data  elements  HVA:  At 
a  nesting  level  of  2,  the  refrences  RVA  consists  of  two  attributes,  ref-type ,  and  refJines.  The 
former  indicates  the  type  of  references  and  the  latter  contains  all  the  lines  which  comprise  the  »iven 
reference. 

At  a  nesting  level  of  3,  the  ref  .lines  RVA  consists  of  two  attributes,  ref-type  which  is  used  to 
keep  the  reference  lines  in  proper  order,  and  refJines  which  are  the  reference  lines  themselves 

At  a  nesting  level  of  2,  the  aliases  RVA  has  three  attributes.  These  attributes  indicate  the 
name  of  the  alias  (name),  where  it  is  used  (where.used)  and  a  comment  line  describing  why  the 
alias  was  needed  (comment). 

At  a  nesting  level  of  2,  the  min.max  RVA  has  three  attributes;  data.type  (the  data  type  of 
this  atomic  data  element):  minimum  (its  minimum  value);  and  maximum  (maximum  value)  Note 
that  this  particular  RVA  will  only  have  one  tuple.  The  decision  to  make  it  an  RVA  is  based  nn  the 
fact  that  there  are  null  values  in  the  case  of  non-atomic  data  elements. 

At  a  nesting  level  of  2,  the  range  RVA  has  two  attributes.  These  attributes  indicate  the 
data  type  of  the  atomic  data  element  (data.type),  and  its  range  of  values  (range).  Note  that  this 
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particular  RVA  will  also  only  have  one  tuple.  The  decision  to  make  it  an  RVA  is  again  based  on 
the  fact  that  there  are  null  values  in  the  case  of  non-atomic  data  elements. 

At  a  nesting  level  of  2,  the  values  RVA  has  two  attributes,  data.type  and  value.  The  former 
identifies  the  data  type  of  the  atomic  data  element,  and  the  latter  indicates  all  legal  values  (this 
applies  to  enumerated  data  types). 

At  a  nesting  level  of  2,  the  activitees  RVA  has  two  attributes,  node. name  and  iconi.hi/it. 
The  former  identifies  the  activity  touched  by  the  data  element,  and  the  latter  identifies  the  role  of 
the  data  element  (input. control. output, mechanism). 

At  a  nesting  level  of  2,  the  children  RVA  contains  a  list  of  all  children  of  this  data  element 
(if  it's  a  pipe),  via  the  single  attribute,  data-name. 

Back  again  at  a  nesting  level  of  1,  the  sheets  RVA  scheme  consists  of  13  attributes  as 
enumerated  below.  As  before,  RVA  are  indicated  in  bold  type,  AVA  are  indicated  in  itahci:ed 
type. 

1  c. n umber  -  the  sheet  identifier  number 
2.  node  -  box  being  decomposed  on  this  sheet 
3  name  -  the  title  of  the  sheet 
1  author  -  the  person  who  drew  the  picture 
h.  version  -  the  revision  number 
<5  date  -  the  date  of  the  drawing 
7.  boxes  -  all  boxes  appearing  on  the  sheet 
f*.  segments  -  the  line  segments  on  the  sheet 
0.  squiggles  -  squiggles  on  the  sheet 
10  meta-note  -  meta  notes  on  the  sheet 
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11.  foot-notes  -  foot  notes  on  the  sheet 


12  feos  -  for  expositions  only 

13  labels  -  labels  for  line  segments 

The  discussion  that  follows  describes  the  RVA  associated  with  sheets:  At  a  nesting  level  <;l 
3.  the  boxes  RVA  has  5  attributes.  Attribute  node  is  the  node  number,  name  is  the  name  of  the 
box.  i  and  y  are  the  location  of  the  upper  left  corner  of  the  box,  and  visible. dre  the  c.number  on 
which  the  box  is  decomposed  or  -1  if  it  is  not  decomposed. 

At  a  nesting  level  of  2,  the  segments  RVA  scheme  consists  of  three  attributes  daln.ul.  lo¬ 
cation.  and  symbols,  which  indicate  the  data  element  being  represented  by  the  segment,  and  the 
location  of  the  segment,  and  the  symbols  that  appear  at  the  ends  of  the  line  segment.  As  always. 
RVA  are  indicated  in  bold  type.  AV'A  are  indicated  in  itahci:ed  type. 

Immediately  below  segments,  at  a  nesting  level  of  3.  the  location  RVA  scheme  consists  "I 
four  attributes  rs.  ijs.  ze.  and  ye.  which  indicate  the  start  and  end  points  of  the  lines  segui'-m 1  ~ i 
for  the  given  data  element. 

Also  below  segments  at  a  nesting  level  of  3.  the  symbols  RVA  scheme  consists  "t  i ■ » 1 1 r 
atiributes;  z  and  y  indicate  the  location  of  the  symbol;  type. symbol  is  the  type  of  symbol,  i  <•  . 
arrow,  boundary,  dot.  to-all/from-all  construct,  tunnel,  or  turn:  and  symbol-type,  the  interpretation 
of  which  depends  upon  type.symbol.  indicates  the  symbol  type.  i.e..  type  of  arrow,  the  icom.code 
tin-  type  of  dot.  the  label  associated  with  a  to-all/from-all  construct,  the  type  of  tunnel  arr<nv.  m 
t  h>-  type  of  turn . 

At  a  nesting  level  of  2.  the  squiggles  RVA  scheme  consists  of  eight  attributes  zl.  yl.  rJ  yJ. 
i  1.  yl.  z.j.  and  y.\  These  attributes  indicate  the  four  points  which  are  connected  together  i  in  the 
"Her  1  —  2  —  3  —  1)  to  make  Ross's  squiggle. 
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At  a  nesting  level  of  2,  the  meta_notes  RVA  scheme  consists  of  four  attributes.  Attribute 
lahfl  is  the  marker  label  for  the  meta.note.  z  and  y  are  the  location  of  the  meta.note  marker,  and 
R\  A  note.text  contains  the  text  associated  with  the  meta.note. 

Immediately  below  meta_notes.  at  a  nesting  level  of  3,  is  the  note.text  RYA  which  has  two 
attributes,  hne.no,  and  tezt.hne.  The  former  attribute  is  used  to  ensure  that  the  text  lines  in  the 
latter  attribute  are  retrieved  in  the  proper  order. 

At  a  nesting  level  of  2,  the  foot  .notes  RVA  scheme  consists  of  six  attributes;  label  indicates 
the  footjiote  marker  label;  zm  and  yin  are  the  location  of  the  footmote  marker:  rn  and  yn  are  the 
location  of  the  footnote  text;  and  RVA  note.text  contains  the  actual  lines  of  text  in  the  footnote. 

Immediately  below  foot  .notes,  at  a  nesting  level  of  3.  is  the  note.text  RVA  which  has  two 
attributes,  hne.no.  and  lezi.lme.  The  former  attribute  is  used  to  ensure  that  the  text  lines  in  the 
latter  attribute  are  retrieved  in  the  proper  order. 

At  a  nesting  level  of  2.  the  feos  RVA  scheme  consists  of  four  attributes;  label  indicates  the 
FEO  marker  label;  r.  and  y  are  the  location  of  the  marker;  and  picture  is  the  name  of  the  text /picture 
file  associated  with  the  FEO8 

At  a  nesting  level  of  2,  the  labels  RVA  scheme  consists  of  four  attributes.  Attribute  drta.id 
identifies  the  data  element  associated  with  the  label,  name  is  the  label  itself,  and  z  and  y  are  the 
location  where  the  label  is  drawn. 

F.'zample  Sested- Relational  Database  Instance.  An  example  database,  containing  the  same 
information  as  the  relational  database,  was  constructed.  As  before,  the  intent  was  to  determine 
if  the  nested-relational  design  had  any  "holes  "  Appendix  H  contains  a  listing  of  the  example 
nested-relational  database. 

"In  a  nested  database  which  supports  objects  of  type  bitmap  (say),  one  could  actually  store  the  picture  in  the 
database. 
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.Vested- Relational  ,'niplementation  Unfortunately,  the  Exodus-based  nested-relational  DBMS 
.■reared  by  Mattkus  does  not  support  all  the  capabilities  required  by  this  real  world  database  ap¬ 
plication.  Accordingly,  a  "paper''  implementation  of  the  nested-relational  design  is  used.  Certain 
•  extensions  to  SQL  which  support  a  nested-relational  database  have  already  been  formalized  by 
Both  and  others  (33).  The  queries  of  the  nested-relational  IDEFq  database  are  developed  using 
lb  th  s  SQL/NF  syntax3.  The  SQL/NF  script  to  create  the  nested-relational  schema  is  shown  in 
Appendix  I.  as  are  the  scripts  to  input,  the  bulk  data  files  into  the  nested-relationai  implementation, 
-how  all  data,  and  erase  all  data. 

SQL/SF  Queries.  The  following  query  extracts  drawing  data  from  the  nested-relational 
IDEFo  aa' abase.  This  data  is  required  by  the  drawing  tool  to  create  the  A-0  diagram  shown 
in  Figure  7.  As  with  the  relational  queries,  the  data  resulting  from  this  query  is  shown,  in  a 
postulated  format,  immediately  following  the  query.  The  items  delimited  by  parenthesis  are  the 
relation-valued  attribute  names. 


SELECT  (SELECT  ILL  BUT  segments . data. id , labels . data. id  FROM  sheets  WHERE  node  *  "A-0") 
FROM  project 

WHERE  project.narae  -  "DM  Example"; 


(sheets) 

I c .number  I  node  I  name  I  author 

I  . I . I . I- . 

II  I  A-0  I  DM  Example  I  Gerald  R.  Morris 


(boxes) 

Inode  I  name  lx  ly  I  risible. DRE  I 


I  AO  Imanage  database  1 1  1 1  12  I 

I . I . I  — I  — I . — . I 


(segments ) 

( locat ion) 

I r«  1  - -  |xe  lye 

| - | - 1 - 1  — 

13  13  14  14 


I 

I 


Ixersion  Idate  I 
I— . I . —  I 

1 1 . 0  102/14/891 

I . I  - . I 


’ '-Hire  the  nested- 1 elational  DBMS  of  Mankus  is  not  used,  the  translate  n  of  SQL/NF  to  the  <  '..thy  dl.egra  I-  n..t 
i ... pored 
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(symbols) 

lx  ly  I  type. symbol  I  symbol. type  I 


4  14  I  arrow  I  right. arrow  I 

- I - 1 - 1 . . 1 


6  16  17  |7  | 


7  | 7  larrow  Idown.arrow  | 


9  19  1 10  UO  I 


—  I  — I - - -I - - 1 

10  1 10  larrow  I  right. arrow  I 


(squiggles) 


Ixl 

lyl 

1x2 

Iy2 

1  x3 

Iy3 

1  x4 

Iy4 

1  _  _  _ 
112 

_  j  _  _  . 
112 

_  |  . 
113 

-  |  - 
113 

_  j _ . 

U4 

1 - 

\  14 

US 

.  | _ 

tis 

| - 1 - 1 - | - 1 - 1 


(meta. notes) 

I  label  lx  |y  I 


| - | - | 

1 . 1-  1 

— i 

(note. text) 

1 line.no 

1  text. line 

(foot. notes) 

1  label  1  xm 

1  ym  1  xn  1  yn  1 

U  Ul 

111  190  190  1 

(note. text ) 

1 line.no 

1 text.line 

11 

Ian  example  decomposition 

12 

Inot  completed 

(f eos) 

1  label  lx 

ly  Ipictnre  1 

(labels) 

l  name 

lx  ly  1 

i userdat a 

12  12  1 

1  rules 

15  IS  1 

1  feedback 

18  18  1 

Appendix  I  includes  additional  SQL/NF  scripts  which  extract  the  drawing  data  lor  the  AO 
diagram,  as  well  as  essential  data  for  a  typical  activity,  and  a  typical  data  element. 
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An  IDEFo  abstract  data  model  is  presented  in  tins  chapter.  The  pi-t ilirai  i< >n  for  a  dual 
modeling  approach  (essential  data  and  drawing  data)  is  developed.  The  relation*  rone-ponding  to 
the  F.-R  diagrams  are  developed,  as  is  an  example  database.  The  relational  design  is  implemented 
in  Ingres  Corporation’s  relational  DBMS,  Ingres.  SQL  queries  to  extract  drawing  data  from  the 
relational  database  are  constructed,  and  the  data  is  used  to  actually  draw  some  IDFF-,  diagrams 
Additional  queries  to  extract  essential  data  are  constructed.  The  relational  design  is  transformed 
into  a  nested-relational  design.  An  example  database  is  constructed.  SQL/NT  queries  to  extract 
data  from  the  nested-relational  database  are  constructed  and  used  to  draw  IDFFo  diagrams.  Ad¬ 
ditional  queries  to  extract  essential  data  are  constructed. 


IV.  FIS  DISCS 


[ill  induction 

This  chapter  summarizes  t he  IDEFo  implementation  within  a  relational  and  ueM.-d-rdar lonal 
DBMS  by  comparing  the  two  implementations  in  several  areas  including  query  complexity.  size  of 
the  database,  and  speed  of  query  execution. 


Query  Complexity 

This  section  considers  the  complexity  of  queries  for  the  relational  versus  nested-relational 
versions  of  the  IDEFo  database.  In  particular,  it  looks  at  the  queries  associated  with  IDEE, 
drawing  data  and  essential  data. 

.4  Definition  of  Complexity.  Obviously  a  database  query  language  complexity  m<-a-ute  could 
include  such  criteria  as  number  of  joins,  number  of  projects,  number  of  binary  comparison  operators, 
number  of  unions,  number  of  nests,  number  of  unnests,  etc.  Unfortunately,  some  of  these  criteria 
do  net  necessarily  apply  to  SQL/NF.  and  others  do  not  apply  to  SQL.  It  is  kind  of  like  comparing 
apples  to  oranges.  Thus,  in  order  to  ensure  some  type  of  commonality,  assume  that  complexity  is 
just  a  simple  count  of  select-from-where  (SFW)  clauses.  This  conservative  approach  actually  favors 
SQL  over  SQL/NF  as  suggested  by  the  following  example: 


Suppose  that  n  is  a  INF  relation  on  scheme  R  i,  and  r2  is  a  INF  relation  on  scheme  It  2 .  where 
/?i  =  (a.b.c),  and  R 2  —  ( b.d.e ).  Suppose  it  is  possible  to  generate  a  nested-relation.  /  ■.  on 
scheme.  Re,  where  Ri  ~  (a,  B.c)  (B  is  a  relation- valued  attribute  such  that  B  —  Ul.>  M  1  lie 
qtierv  of  interest  is  the  entire  database.  The  queries  are: 

select  r\  a.  /  i  b.  iq  c.  r2  d.  r;  e  /*  SQL  */ 
from  ri  .  r : 
where  r  1  b  =  r _  l). 


select  ALL  fiotn  r • .  /•  SQL/NF  •/ 


Esing  the  simple  complexity  measure  suggested  above,  both  queries  appear  to  have  the  same 
complexity  since  they  both  have  a  single  SFW  clause.  It  is  easy  to  show  that  the  SQL  query  which 
involves  a  natural  join,  is  more  complex,  both  from  a  user  viewpoint,  and  an  internal  execution 
viewpoint.  The  user  viewpoint  is  obvious;  an  intimate  knowledge  of  the  mnichiiig  k.  v-  w.|| 
the  syntax  for  creating  a  natural  join  are  required.  The  internal  viewpoint  i-  has.-d  iq...u  „  .me 
knowledege  of  how  the  nested-relational  implementation  works.  Basically,  any  efficient  nested- 
relational  implementation  will  keep  all  the  tuples  in  a  nested  relation  on  contiguous  blocks  of 
the  disk.  The  Exodus  storage  manager  allows  for  this  to  occur.  It  defines  a  storage  object  as  "an 
uninterrupted  container  of  bytes  which  can  range  in  size  from  a  few  bytes  to  hundreds  of  megabytes" 
i.'iT).  In  short,  the  nested-relational  version  requires  the  storage  manager  to  return  one  or  more 
contiguous  blocks  from  the  disk.  The  relational  version,  on  the  other  hand,  will  have  to  use  some 
type  of  join  strategy,  e.g.,  block-oriented  iteration,  to  generate  the  required  tuples,  (leiierallv  this 
results  m  multiple  disk  accesses  from  non-contiguous  blocks,  even  if  both  relations  have  clustered 
indices  on  the  join  attribute. 

rims,  by  using  the  simple  criteria  above,  the  results  are  conservative  That  is  to  say.  the 
•  xteiit  to  which  SQL/NF  appears  to  be  "better"  than  SQL  is  understated. 

The  complexity  measure  discussed  above  can  he  formalized  as,  C,  t„  (qut  »•//)  =  ‘he  number 
of  SEW  clauses  in  query.  Note  that  C,fw  is  additive;  if  extraction  of  a  data  set  involves  n  quert-s. 
then  the  complexity  of  the  query  for  the  entire  data  set  is  given  by 


n 

C3/H  (iutai)  =  Y'  C, ;.,  (•!  uery, ) 
1=1 


u  !ki>'  (  ’9/tt  (query t )  is  the  complexity  of  the  i'th  <piery 


Data  definition  language  (DDL)  statements,  and  data  manipulation  language  (DML)  state¬ 
ments,  which  may  not  involve  SFW  clauses,  need  additional  complexity  definitions. 

In  the  case  of  DDL  statements,  the  complexity  is  given  by  by  Cddi  =  na  +  n,.  where  na  is  the 
number  of  atomic  attributes,  and  nt  is  the  number  of  TABLE  clauses. 

For  DML  statements  which  perform  a  bulk  load,  the  complexity  is  given  L>  (  '/..  ,.t  =  »/.,  •+• 

where  na  is  the  number  of  atomic  attributes,  nrva  is  the  number  of  relational-valued  attributes, 
and  rtf  is  the  number  of  COPY  TABLE  clauses. 

For  DML  statements  which  delete  data,  the  complexity  is  defined  as  C./,i  =  1  -r  n,fu  .  since 
there  is  always  at  least  one  DELETE  keyword,  and  n,jw  SFW  clauses  (n,/n  =  0  is  allowed). 

The  SQL  and  SQL/NF  scripts  in  this  thesis  do  not  include  any  INSERT  or  f'PDATE  DML 
statements.  Neither  do  they  involve  NEST  or  UNNEST.  Accordingly,  complexity  measures  associ¬ 
ated  with  these  types  of  statements  are  not  defined. 

Comparison  of  SQL  versus  SQL/NF.  Having  formalized  the  meaning  of  "complexity,"  it  is 
now  possible  to  compare  the  relational  SQL  queries  with  the  nested-relational  SQL/NF  queries.  A 
direct  comparison  of  the  drawing  data  and  essential  data  queries  illustrate  rather  profoundly  ’he 
simplicity  of  the  SQL/NF  queries1  as  shown  in  Table  7.  From  a  more  intuitive  viewpoint  relative 
to  the  nested  version,  all  the  data  is  nested  exactly  where  it  is  needed,  the  requirement  lor  |oins  is 
iiiiiiimtzed/eliiiiinated,  as  is  the  requirement  for  multiple  queries  from  multiple  relations 


Table  7.  Comparison  of  Query  Script  Complexity 


Query 

C,  f,c 

A-0  activity  drawing  data 

SQL 

SQL/NF 

16 

1 

AO  activity  drawing  data 

10 

1 

A1  activity  essential  data 

< 

1  j 

unumber  data  element  essential  data 

14 

1 

average 

21.5 

1 

’  Recall  these  numbers  are  conservative. 


The  create  tables  scripts  for  SQL  and  SQL/NF  are  on  the  same  order  of  complexity  since, 
at  some  point,  all  the  atomic  attributes  must  be  defined.  Even  so.  because  of  the  many  to  many 
relationships  in  the  IDEFo  abstract  data  model,  the  relational  version  needs  to  have  a  number  of 
relations  just  to  resolve  the  many  to  many  conflict.  The  load  tables  scripts  are  also  on  the  same 
order  of  complexity  since,  once  again,  all  atomic  attributes  must  be  referenced  On  the  other  hand, 
the  erase  tables  script  for  SQL/NF  is  clearly  less  complex  since  there  is  only  one  table  to  erase! 
The  actual  complexity  measures  are  shown  in  Table  8. 


Table  8.  Comparison  of  DDL/DM L  Script  Complexities 


SQL 

Cut 

S'* 

load 

C.ui 

161 

137 

40 

SQL/NF 

113 

119 

1 

Size  of  Database 

This  section  considers  the  relative  sizes  of  the  relational  implementation  and  nested-relational 
implementation  of  the  IDEFo  database.  Unfortunately,  a  direct  comparison  is  not  possible  since 
the  nested-relational  DBMS  build  by  Mankus  does  not  have  all  the  features  necessary  to  implement 
a  complex  nested-relational  application  such  as  IDEFo-  Fortunately,  the  logical  comparision  is  still 
possible  and  is  presented  below. 

Relational  Logical  Size.  In  the  relational  instance  the  algorithm  for  determining  logical  size  is 
to  count  the  number  of  bytes  per  tuple  in  each  relation,  determine  the  number  of  tuples,  and  then 
mult i ply  t ne  two.  The  example  shown  in  Table  9,  taken  from  Roth,  illust rates  t lie  idea  ( .1:1: 102 ) 

Suppose  attribute,  dno  requires  4  bytes;  dname  requires  15;  and  loc  requires  10  Assume  there 
are  10  tuples  in  the  database.  Since  each  tuple  uses  29  bytes  and  there  are  10  tuples,  the  logical 
size  of  the  database  is  29  x  10  =  290. 

A  similar  analysis  of  the  IDEFo  relational  database  instance  is  shown  m  Table  11 
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Table  9.  Simple  Relational  Example 


Dept 


dno 

dname 

loc 

10 

Manufacturing 

Austin 

20 

Personnel 

Dallas 

30 

Retail 

Austin 

_ 

Xested-Relational  Logical  Size.  In  the  nested-relational  instance,  the  approach  is  tc 
the  number  of  bytes  used  by  the  atomic  attributes  in  each  each  relational-valued  attribute 
the  total  number  of  tuples  in  each  RY'A,  and  then  multiply  the  two.  The  rumple  example  *| 
Table  10,  taken  from  Roth,  illustrates  the  idea  (33:100). 


Table  10.  Simple  Nested- Relational  Example 

Supply _ 


supplier 

Supplies 

pari 

42 

7 

8 

9 

10 

18  . 

20 

21 

45 

8 

10 

32 

34 

38 

56 

3 

5 

10 

41 

Suppose  the  supplier  atomic  attribute  uses  5  bytes,  and  the  part  atomic  attribute 
bytes  Since  there  are  3  occurrences  of  a  Supply  tuple  and  16  occurrences  of  a  Supplies  tu 
logical  size  of  the  database  is  5  x  3  +  3  x  16  =  63.  A  similar  analysis  of  the  IDEF(>  nested-re 
d,  taba.se  is  shown  in  Table  12. 


i  count 
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The  latter  results  hear  some  explanation  since,  in  general,  nested- relations  are  small  then  their 
relational  counterparts.  To  make  joins  more  efficient  in  the  relational  design,  globally  unique  integer 
"id "  attributes  were  used  in  lieu  of  the  "real”  superkeys.  Since  the  nested-relational  version  avoids 
joins  as  much  as  possible,  it  would  have  been  counterproductive  to  include  such  "id"  attributes.  Not 
including  them  naturally  increases  the  size  of  the  nested-relational  model  since  all  the  attributes 
must  be  stored.  This  is  perhaps  best  understood  by  way  of  some  examples. 

Suppose  that  the  activity  relation  had  stored  the  12  character  project  name  as  the  join 
attribute  instead  of  the  4  byte  integer,  project-id,  the  resulting  size  of  an  activity  tuple  would  be 
90  bytes  as  opposed  to  82  bytes.  In  the  case  of  data.elem.  the  size  of  a  tuple  would  have  been 
01  bytes  as  opposed  to  53  bytes.  The  space  savings  associated  with  the  2  byte  integer,  author.id. 
as  opposed  to  the  20  byte  character  string,  author,  is  18  bytes  per  tuple  for  both  activity  and 
<lata_elem.  Perhaps  the  biggest  savings  is  in  the  cross  reference  tables.  For  example,  assume 
activity  used  its  "rear  key,  project-name,  which  is  a  12  byte  character  string,  and  node,  which 
is  a  20  byte  character  string,  in  lieu  of  the  4  byte  integer  key.  node-id  Further  suppose  that 
data-elem  used  project-name,  and  data-name,  which  is  a  25  byte  character  string,  in  lieu  of  the  4 
byte  integer,  data Jd.  Consider  the  effect  on  the  act2data  cross  reference  relation.  Since  attribute 
iroin.code  remains  the  same,  but  a  the  other  two  attribu'es,  node. id,  and  data.id  are  changed  as 
just  described,  one  tuple  of  act2data  would  require  70  bytes  instead  of  9  bytes  In  short,  the  size 
savings  associated  with  the  relational  version  has  to  do  with  the  design  decision  to  use  global  integer 
"ii!"  values  in  lieu  of  the  'real”  keys;  it  is  not  an  intrinsic  feature  of  the  relational  model.  Thus,  the 
nested-relational  instance,  which  uses  6,579  bytes,  takes  up  more  room  than  the  relational  instance, 
which  only  uses  6,086  bytes. 
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Table  11.  Logical  Size  of  Relational  Instance 


BYTES 


8 


RELATION 


act‘2act 


art2data 


act2hist 


act2ref 


activity 


act.descr 


alias 


arrow- 


boundary 


data2data 


data2label 


data2ref 


data2value 


data.changes 


data.descr 


data.elem 


data_range 


data.type 


data.value 


dot 


feo 


footnote 


graphics 


hist-call 


label 


min  jnax 


note 


note. text 


project 


reference 


ref.type 


segment 


squiggle 


symbol 


to.from.all 


tunnel 


turn 


TOTAL  STORAGE 


TUPLES 


2 


STORAGE 


16 


0 

1 

1 

9  i 

162 

16  ! 

1.254 
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Table  12.  Logical  Size  of  Nested-Relational  Instance 


RELATION /RVA 

ATOMIC 

BYTES 

TUPLES 

STORAGE 

PROJECT 

12 

1 

12  | 

activities 

176 

3 

528  ] 

act.desct 

62 

372  | 

refrences 

25 

4 

100 

refJines 

62 

6 

372  ! 

hist.calls 

32 

1 

32  1 

data.elems 

26 

9 

234 

children 

25 

2 

50 

data.elements 

152 

n 

1.672 

data.descr 

62 

14 

868 

refrences 

25 

9 

225 

refJines 

62 

12 

744 

aliases 

75 

0 

0 

min-max 

55 

0 

0 

range 

86 

0 

values 

30 

2 

60 

children 

25 

6 

150 

sheets 

87 

2 

174 

boxes 

51 

3 

153 

segments 

■4 

14 

56 

location 

8 

21 

168 

symbols 

8 

26 

208 

squiggles 

16 

1 

16 

meta_notes 

5 

0 

n 

note.text 

62 

0 

0 

foot-notes 

9 

1 

9 

note.text 

62 

•> 

124 

feos 

65 

0 

0 

labels 

18 

14 

252 

|  TOTAL  STORAGE 

6.579 

Eyeed  of  Query  Execution 

1  Ins  section  considers  the  speed  of  query  execution  for  the  relational  implementation  and 
m'-'ti d-relational  implementation  of  the  IDEFo  database.  Unfortunately,  a  directly  measurable 
comparison  is  not  possible  since  the  nested-relational  DBMS  build  by  Manktis  does  m a  have  ,-|||  the 
features  necessary  to  implement  a  complex  nested-relational  application  such  as  IDFF  However,  it 
is  still  possible  to  compare  the  implementations  from  two  different  perspectives.  The  first  approach 
a.s.-umes  that  tne  applicable  tuples  are  fetched  from  the  disk  as  needed.  Speed  is  determined 
based  upon  a  conservative  assumption  as  to  the  number  of  disk  accesses  needed.  The  second 
approach  assumes  that  the  entire  data  set  associated  with  a  given  project  is  small  enough  to  fit 
in  main  memory.  Speed  is  determined  via  an  order-of  analysis  of  a  typical  prograi.  that,  talks 
to  the  database  via  embedded  language  queries.  The  initial  load  at  run  time,  and  final  flush  at 
termination  time  are  ignored. 

Disk  Resident  Project  Data.  In  order  to  determine  the  relative  speeds  of  the  queries,  certain 
conservative  estimates  are  made  relative  to  physical  mapping  of  the  data  onto  the  disk 

Assume  that  the  relational  DBMS  has  memory  resident  clustered  13+  tree  indices  on  the  join 
attributes.  Further  assume  that  the  DBMS  is  "smart"  enough  to  store  relations  'hat  are  likely 
to  be  joined  in  close  proximity  to  one  another  on  the  disk.  Based  upon  these  highly  optimistic 
assumptions,  assume  that  it  takes  one  disk  access  for  every  two  relations  involved  in  a  join.  Formally, 
tin*  number  of  disk  accesses,  nJV;,  for  a  relational  (SQL)  query  is  given  by 


where  nr  is  the  number  of  unique  relations  involved  in  the  query  being  considered 

Assume  that  the  nested-relational  DBMS  stores  the  data  m  contiguous  locations  "ti  th»>  disk, 
and  that  it  takes  two  accesses  to  retrieve  a  given  set  of  tuples  for  the  queries  considered  11"' 
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latter  is  actually  a  fairly  good  assumption.  The  example  database  instance  shown  above  is  around 


s  kilo-bytes,  which  includes  three  activities,  eight  data  elements,  and  two  sheets  Considering  that 
a  2k  to  4k  page  size  is  typical,  it  seems  reasonable  to  presume  a  query  for  a  given  sheet,  activity, 
or  data  element  could  be  done  with  just  two  accesses.  As  to  the  contiguous  storage  assumption, 
Exodus  definitely  allows  this  capability  tvs  discussed  in  the  Exodus  Storage  Manager  guide  (.VI). 
In  short,  the  assumptions  seem  to  be  reasonable.  The  last  assumption  is  that  a  memory  resident 
index  identifies  the  appropriate  disk  locations.  Formally,  the  number  of  disk  accesses,  n for 
the  given  nested-relational  (SQL/NF)  queries  is  given  by 


ftsijln  J  —  2- 


Table  13  shows  the  results  for  the  queries  given  in  Chapter  3 


Table  13.  Relative  Query  Speeds:  Number  of  Disk  Accesses 


Query 

warn 

A-0  activity  drawing  data 

17 

2 

AO  activity  drawing  data 

2 

A1  activity  essential  data 

13 

2 

unumber  data  element  essential  data 

25 

2 

average 

2 

Memory  Resident  Project  Data.  Obviously  a  tool  which  uses  the  IDEFo  database  needs  to 
talk  to  the  database.  The  mechanism  with  which  a  high-level  language  such  as  C  or  Ada  interfaces 
with  the  resident  DBMS  is  the  embedded  query  language  call.  The  next  two  sections  consider  such 
embedded  query  language  calls  for  the  Ingres  relational  IDEFo  implementation  and  t It*'  nested- 
relational  implementation.  The  assumption  is  that  the  entire  dataset  for  a  given  project  is  small 
enough  to  fit  into  main  memory.  Note  that  certain  liberties  are  taken  relative  to  syntax.  The 
important  issue  here  is  the  concept  (semantics),  not  the  syntax! 
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Embedded  SQL  Example.  Embedded  SQL  in  Ingres  involves  the  concept  of  a  cursor 
(28:3-7).  Basically,  a  “template'’  SQL  statement  is  created,  along  with  some  data  structures  that 
are  “visible"  to  SQL.  Whenever  the  embedded  SQL  call  is  made,  the  next  tuple  is  placed  in  the 
visible  data  structures.  Consider  the  following  C  header  file  which  defines  the  types  needed  to 
contain  the  screen  data  in  the  IDEF0  database  (an  analogous  set  of  Ada  type  definitions  is  given 
in  Appendix  J ): 


/•  This  header  defines  th«  data  structures  that  ara  usad  to  capture  tha 
drawing  data  from  tha  IDEFO  databasa  »ia  embaddad  query  language  calls 
It  is  not  known  apriori  how  many  tuples  there  are,  so  a  linked  list 
structure  is  used. 

The  element  names  correspond  identically  to  the  attribute  names  used  in 
the  IDEFO  database.  It  is  assumed  the  user  of  this  header  is  familiar 
with  the  database  schema. . .  •/ 

typedef  struct  box{ 

char  node(21] ,name[26]  ; 
int  x ,y ,visible_dre ; 
struct  box  *next_box; 

}  «boxptr; 

typedef  struct  loc{ 
int  xs,ys,xe,ye; 
struct  loc  »next_loc; 

}  *locptr; 

typedef  struct  symbol{ 
int  x.y; 

char  type_symbol[13] .symbol. type[13] ; 
struct  symbol  «next_ symbol ; 

}  *symbolptr; 

typedef  struct  seg{ 
loeptr  location; 
symbolptr  symbols; 
struct  sag  enext.seg; 

>  «segptr; 

typedef  struct  squig{ 

int  xl ,yl ,x2 ,y2,x3 ,y3 ,i4,y4 ; 
struct  squig  ‘next.squig; 

>  esquigptr; 

typedef  struct  note_txt{ 
int  line.no; 
char  text.lineCl . .61] ; 
struct  note.txt  enext.note.txt; 

}  *note_txtptr; 


/•  pointer  to  next  box  •/ 

/•  type  boxptr  points  to  a  box  structure  •/ 
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typadef  struct  meta{ 
char  label[2]  ; 
int  x,y; 

note.txtptr  nota.taxt; 
struct  meta  *next_meta; 

}  *m«taptr; 

typadef  struct  foot{ 
char  label [2] ; 
int  xn,yx,xn,yn; 
note.txtptr  nota.taxt; 
struct  foot  «next_foot; 

}  afootptr; 

typadef  struct  feo{ 
char  label[2] ; 
int  x,y; 

char  picture  [61] ; 
struct  fao  »next.feo; 

]  «feoptr; 

typedaf  struct  label{ 
char  nane[ll] ; 
int  x,y; 

struct  labal  *next .label; 

}  *labelptr; 

typadef  struct  shaatC 
int  c. number; 

char  noda[21] ,nana[26] ,author[21] ,version[ll] ,data[9] ; 

boxptr  boxes; 

segptr  segnents ; 

squigptr  squigglas; 

met apt r  mata.notes; 

footptr  foot .notes; 

feoptr  feos; 

labelptr  labels; 

>  *sheetptr; 

/•  and  soae  other  stuff  as  sell  •  / 


Given  this  header  file,  which  defines  the  data  structures  needed  to  draw  the  screen,  a  procedure 
must  now  make  the  appropriate  embedded  SQL  calls,  load  the  resulting  tuples  in  the  screen  drawing 
structure,  and  then  call  the  screen  drawing  procedure.  The  following  elided  routine  illustrates  the 
concept: 
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/*  Obligatory  procedura  header,  includes,  et  al  •  / 

draw.the.a.minus.zero.screenCthe.project.name , . .  )  /•  relational  version  •/ 

/•  required  parameter  declarations  •  / 

{ 


/•  perform  necessary  initialization  to  talk  to  Ingres  SQL  •  / 


/•  declare  C  variables  that  are  visible  to  SQL.  lote  that  strings 
gotta  be  one  more  since  C  uses  a  null  byte  to  teminate  strings  •  / 


EXEC  SqL  BEGII  DECLARE  SECTIOI; 
char  pro ject.name ; 

/•  declare  the  variables  for 
int  x,y, 

visible.dre , 
c.number ; 
char  name [26] , 
date [9]  , 
author [21]  , 
version[ll]  ; 

/•  declare  the  variables  for 


/«  name  of  project  •/ 
the  first  query  »/ 

/•  coordinates  of  bor  •/ 

/*  true  if  this  box  is  decomposed  •/ 
/»  sheet  on  ehich  it  is  decomposed  •/ 
/»  activity  name  */ 

/•  data  of  the  revision  */ 

/»  name  of  analyst  •/ 

/•  revision  number  •/ 
the  remaining  queries  •/ 


EXEC  SQL  EID  DECLARE  SECTIOI; 


/*  Create  some  local  linked  list  structures  to  hold  all  the  stuff 
until  you  can  allocate  the  screen  draaing  data  structure. 
Recall,  we  don’t  knoe  its  size  yet.  .  .  •  / 


/•  let  SQL  "see"  the  name  of  the  project  •/ 
st rcpy (pro ject .name ,  the. project. name) ; 

/•  Open  Database  •/ 


/*  Create  query  cursor,  basically  this  is  a  prototype  of  the 
desired  SQL  query  that  is  to  be  performed.  This 
cursor  is  used  to  generate  the  first  part  of  the  A-0  sheet  •  / 

EXEC  SQL  DECLARE  a.minus.O.f irst. cursor  CURSOR  FOR 

select  a. x, a. y, a. name, a. date, an. author, a. vers  ion, a. vis ible.DRE.s. c.number 
from  activity  a,  analyst  an,  sheet  s 
where  a. node  ■  "AO"  and 
a. author. id  «  an. author. id  and 
s  sheet. id  »  a. sheet. id  and 
a  project. id  in  ( 
select  p. project. id 
from  project  p 

where  p.name  »  : project.name) ; 

/•  Open  cursor  and  prepare  to  perform  the  query  •/ 

EXEC  SQL  OPEI  a.minus.O.f irst.cursor ; 

EXEC  SQL  UHEIEVER  I0T  FOUID  GOTO  dunl ;  /•  Branch  when  done  -  Ugh!  •/ 

/•  Query  loop  •/ 

whiled)  {  /•  until  the  stinking  goto  above  is  taken  •/ 

/•  Fetch  next  tuple  via  defined  cursor  and  put  the  resulting 
tuple  into  the  C  variables  defined  above  •/ 

EXEC  SQL  FETCH  a.minus.O.f irst.cursor  IITO 

x.  :y,  name,  :date,  author,  :version,  : visible.dre ,  c. number; 

/•  allocate  a  nee  node  to  save  this  data  •/ 
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/*  fetch  next  tuple  (none  in  this  case)  »/ 

> 

dunl :  /•  lo  more  tuples;  do  shatever  clean  up  is  necessary  •  / 

/•  Close  cursor  •/ 

EXEC  SQL  CLOSE  a.minus.O.f irst.cursor ; 

/*  Define  the  next  cursor 

and  grab  the  data  in  a  query  loop 

and  at  each  pass,  allocate  a  nes  local  node  to  keep  the  data, 
and  load  it  into  the  nee  node  •  / 


/*  Define  the  next  cursor 
. .  ad  nauseaua. . .  •/ 


/•  Close  database  •/ 


/>  non  that  the  data  is  available,  create,  allocate,  and  load  a  sheetptr 
type  data  structure  to  send  to  the  drawing  routine  •/ 
sheetptr  the. sheet; 

/*  now  that  the  data  is  loaded,  call  the  draw  screen  procedure  •/ 
draw. screen(the. sheet) ; 

>  /•  that’s  all  folks  •/ 


In  order  to  assess  the  worst  case  time  complexity  of  this  code,  it  is  necessary  to  look  at  the 
definition  of  Big-O  and  order-of: 


Definition  of  Big-O: 

A  function  f(n)  is  of  order  0(g(n))  if  and  only  if  there  exist  constants,  c  >  0  and  n0  >  0, 
such  that 

f(n)  <  c  g(n)  Vn  >  n0 

f(n)  =  0(g(n))  says  that  j(n),  multiplied  by  some  constant,  c,  gives  an  upper  bound 
on  f(n).  (21) 


The  code  shown  above  would  actually  involve  ten  different  cursors  and  query  loops,  as  *een 
in  Appendix  G.  The  first  loop  always  has  exactly  one  tuple,  and  is  therefore  of  time  order,  0(1). 
The  second  loop  is  of  time  order,  O(s),  where  s  is  the  number  of  segments  on  the  A-0  diagram. 
The  third  loop  is  of  time  order,  O(a),  where  a  is  the  number  of  arrow  symbols.  The  fourth  loop  is 
of  time  order,  0(f),  where  t  is  the  number  of  turn  symbols.  The  fifth  loop  is  of  time  order,  Q(n), 
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where  u  is  the  number  of  tunnel  arrow  symbols.  The  sixth  loop  is  of  time  order.  0(1).  where  /  is  the 
number  of  labels.  The  seventh  loop  is  of  time  order,  O(q).  where  q  is  the  number  of  squiggles  on 
the  A-0  diagram.  The  eighth  loop  is  of  order,  O(f),  where  /  is  the  number  of  footnotes.  Although 
not  shown  in  the  example  A-0  diagram  in  this  thesis,  a  generalized  A-0  drawing  might  include 
meta-notes  and  FEO  constructs.  These  would  require  two  additional  loops,  which  would  run  on 
the  order  of,  O(m)  (number  of  meta-notes),  and  0(p )  (number  of  FEO  pictures  associated  with 
the  diagram).  In  all  the  cases  above,  the  constants  would  depend  upon  the  machine  used,  system 
loading  (in  a  multiuser  environment),  etc.  Nonetheless  the  order-of  analysis,  in  conjunction  with 
the  fact  that  there  are  10  sequential  loops,  does  give  an  indication  that  the  embedded  SQL  queries 
could  be  potentially  slow.  This  rings  particularly  true  since  for  each  of  the  10  queries,  there  is 
a  separate  parsing,  optimization,  and  extraction.  In  addition,  the  queries  all  involve  a  multi-way 
join.  As  discussed  in  the  previous  section,  this  is  likely  to  be  an  expensive  process. 

Embedded  SQL/NF  Example.  The  prototype  nested-relational  DBMS  built  by  Mankus 
does  not  support  embedded  SQL/NF.  Accordingly,  postulate  the  existence  of  such  a  capability 
Assume  it  is  along  the  same  lines  as  the  embedded  SQL  in  Ingres.  A  call  to  embedded  SQL/NF 
gets  the  next  tuple,  much  like  Ingres  embedded  SQL.  However,  since  a  "single  tuple"  contains 
relational-valued  attributes,  the  embedded  SQL/NF  must  automatically  allocate  space  in  a  linked- 
list  structure  which  receives  the  data.  In  short,  assume  that  embedded  SQL/NF  requires  a  cursor, 
which  is  again  a  "template"  SQL/NF  statement,  and  some  linked-list  data  structure  which  is 
"visible”  to  SQL/NF.  Whenever  the  embedded  SQL/NF  call  is  made,  the  next,  tuple  is  placed  in 
the  linked  list  along  with  all  tuples  in  its  relational-valued  attributes. 

Assume  the  header  file  mentioned  in  the  previous  section  is  available.  The  following  elided 
routine  illustrates  the  embedded  SQL/NF  call: 
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/•  Obligatory  procedure  header,  includes,  et  al  */ 

dra«_the.a.ainus_zero.screen(the.project.naae , .  .  . ) 
/*  nested-relational  version  •/ 

/•  required  parameter  declarations  ♦  / 


/*  perform  necessary  initialization  to  talk  to  SQL/IF  •  / 

/•  declare  C  data  structures  that  are  visible  to  SQL/IF.  */ 
EXEC  SQLIF  BECII  DECLARE  SECTIOI; 

char  pro ject.name ;  /•  name  of  project  •/ 

sheet. ptr  the. sheet;  /•  the  entire  enchilada!  »/ 

EXEC  SQLIF  EID  DECLARE  SECTIOI; 

/•  let  SQLIF  "see"  the  name  of  the  project  •/ 
strcpyCproject.name ,  the. pro ject.name) ; 

/•  Open  Database  */ 


/•  Create  query  cursor,  basically  this  is  a  prototype  of  the 
desired  SQLIF  query  that  is  to  be  performed.  This 
cursor  is  used  to  generate  the  entire  A-0  sheet  •  / 

EXEC  SQLIF  DECLARE  a.minus.O. cursor  CURSOR  FOR 

SELECT  (sheets  ALL  BUT  segments  data. id .labels  data. id  WHERE  node  *  "A-O") 
FROH  project 

WHERE  project.name  »  : pro ject.name ; 

/•  Open  cursor  and  prepare  to  perform  the  query  •/ 

EXEC  SQLIF  OPEI  a.minus.O. cursor; 

/«  Fetch  next  tuple  via  defined  cursor  and  pur  the  resulting 
tuple  into  the  the.sheet  defined  above  */ 

EXEC  SQLIF  FETCH  a.minus.O. cursor  IITO  : the.sheet; 

/•  Close  cursor  •/ 

EXEC  SQLIF  CLOSE  a.minus.O.cursor ; 

/•  Close  database  •/ 


/•  los  that  the  data  is  loaded,  call  the  dras  screen  procedure  */ 
drav.screenC the.sheet ) ; 

}  /•  that’s  all  folks  •/ 


[u  the  case  of  SQL/NF,  there  is  a  single  cursor  and  query  (recall  there  is  a  single  tuple  per 
sheet).  Accordingly,  the  procedure  is  of  time  order,  0(  l).  Now  obviously  the  constant  for  a  nested 
query  will  be  different  than  the  constant  for  a  non-nested  query.  Even  so,  there  is  a  single  parsing, 
optimization,  and  extraction.  Accordingly,  it  seems  reasonable  to  suggest  that  the  SQL/NF  query 
will  run  faster.  Obviously,  the  actual  speed  depends  a  great  deal  upon  the  particular  machine, 
system  loading,  etc. 
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Summary 


This  chapter  summarizes  the  IDEFo  implementation  within  a  relational  and  nested-relational 
DBMS. 

A  conservative  definition  of  query  complexity  is  presented,  and  used  to  determine  the  relative 
complexities  of  SQL  (relational)  queries,  and  SQL/NF  (nested-relational)  queries.  The  average 
complexity  of  the  relational  (SQL)  queries  is  an  order  of  magnitude  (21.5  times)  more  complex 
than  the  average  complexity  of  the  nested-relational  (SQL/NF)  queries. 

The  logical  size  of  the  relational  and  nested-relational  instances  are  derived.  The  larger  size 
of  the  nested-relational  instance  (6,579  bytes)  as  compared  to  the  relational  instance  (6,086  bytes) 
is  due  to  the  use  of  integer  "id”  attributes  in  the  relational  design;  it  is  not  due  to  some  intrinsic 
quality  of  relational  versus  nested-relational  designs. 

The  speed  of  execution  for  queries  is  presented  from  two  aspects;  a  disk  bas^d  DBMS  wherein 
the  number  of  disk  accesses  determines  the  speed;  and  a  memory  resident  DBMS  wherein  the  speed 
of  execution  is  determined  via  program  run  time. 

Disk-based  relational  (SQL)  queries  require  an  average  of  22.75  disk  accesses.  Disk-based 
nested-relational  (SQL/NF)  queries  require  an  average  of  2  disk  accesses. 

An  order-of  analysis  is  used  to  determine  the  relative  speeds  of  queries  for  the  memory  resident. 
DBMS.  A  program  containing  embedded  SQL  (relational)  queries  to  extract  the  A-0  drawing  data 
runs  in  linear  time  based  upon  the  number  of  graphical  constructs  in  the  diagram.  A  program 
containing  embedded  SQL/NF  (nested-relational)  quereis  to  extract  the  A-0  drawing  data  runs  in 
constant  time.  Obviously  the  constants  associated  with  the  order-of  analysis  are  dependent  upon 
the  particular  machine,  operating  system,  numer  of  users,  etc. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


Introduction 

This  chapter  summarizes  and  presents  conclusions  about  the  research:  it  also  includes  some 
recommendations  as  to  further  research  in  this  area. 

Summary 

This  research  effort  accomplished  several  objectives  relative  to  the  design  of  both  a  rela¬ 
tional  and  nested-relational  database  to  handle  the  IDEFo  analysis  language  data.  The  primary 
accomplishments  include  the  following: 

1.  Developed  a  partitioned  abstract  data  model  of  IDEFo  which  included: 

•  An  essential  data  model. 

•  A  drawing  data  model. 

2.  Developed  a  relational  DBMS  to  handle  the  IDEFo  language  data  which  included: 

•  Mapping  the  abstract  data  model  into  a  relational  design. 

•  Implementing  the  relational  design  in  the  Ingres  DBMS. 

•  Creating  an  example  database  instance. 

•  Developing  SQL  queries  which  extract: 

-  Drawing  data. 

-  Essential  data. 

3.  Developed  a  nested-relational  DBMS  to  handle  the  IDEF0  language  data  which  included: 

•  Mapping  the  relational  design  into  a  nested-relational  design. 

•  Creating  an  example  database  instance. 
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•  Developing  SQL/NF  queries  which  extract: 


-  Drawing  data. 

-  Essential  data. 

-1.  Compared  the  relational  and  nested-relational  versions  in  terms  of: 

•  Complexity  of  queries. 

•  Size  of  the  database. 

•  Speed  of  query  execution. 

<  '(inclusions 

The  partitioned  abstract  data  model,  while  more  complex,  allowed  the  drawing  data  to  be 
>eparated  from  the  essential  data. 

In  the  nested-relational  design,  the  drawing  data  and  essential  data  were  completely  separated. 
In  rhis  sense,  the  nested-relational  version  more  closely  modeled  the  abstraction  generated  via  the 
l.-R  analysis 

I  he  rnmplexity  results,  which  were  based  on  metrics  that  favor  SQL  over  SQL/NF,  clearly 
-hi  wed  the  advantage  of  the  nested-relational  version  over  the  relational  version  for  the  particular 
t  of  queries  considered  On  average,  the  relational  queries  (SQL)  were  an  order  of  magnitude 
i '21  ')  times)  more  complex  than  the  equivalent  nested-relational  (SQL/NF)  queries. 

The  nested  relational  instance  had  a  slightly  larger  logicalsize  when  compared  to  the  relational 
instance.  It  was  shown  that  this  was  a  result  of  optimizing  the  relational  design  via  use  of  global 
integer  "id"  attributes  instead  of  the  "real”  keys.  Even  so,  the  apparent  benefits  of  simpler  queries 
and  faster  execution  times  would  seem  to  offset  the  increased  size.  Obviously  from  a  user  perspective 
this  is  desirable  (assuming  the  storage  is  available). 
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The  query  speeds  of  the  disk-based  DBMS  model  clearly  showed  the  advantage  of  the  ue.sted- 
i<dational  version  over  the  relational  version.  On  average,  t lie  relational  (SQL)  queries  required 
22.75  disk  accesses  whereas  the  nested-relational  queries  only  required  an  average  of  2  disk  accesses 
I'li is  is  an  order  of  magnitude  speedup.  In  large  part,  this  is  due  to  t he  assumpi  ion  of  a  eont  iguous 
storage  model  for  the  nested-relational  DBMS.  An  object-oriented  storage  mod-j.  Midi  Exodus 
(5).  does  allow  this  capability. 

The  query  speeds  for  the  memory-based  DBMS  model  also  showed  that  the  nested-relational 
version  has  an  advantage  over  the  relational  version.  The  running  time  of  the  embedded  SQL/NF 
program  which  extracts  the  A-0  drawing  data  is  of  order,  0(1);  the  running  time  of  the  embedded 
.SOL  program  is  of  order,  0(max(s.a,t,uj,q,f,m,p)),  where  s  is  the  number  of  segments,  a  is 
the  number  of  arrow  symbols,  t  is  the  number  of  turn  symbols,  u  is  the  number  of  tunnel  arrow 
symbols,  /  is  the  number  of  labels,  q  is  the  number  of  squiggles,  /  is  the  number  of  footnotes,  in  is 
the  number  of  meta-notes,  and  p  is  the  number  of  for-exposition-only  picture  constructs.  Obviously 
the  constants  associated  with  big-0  depend  upon  the  machine  used,  system  loading  (in  a  multiuser 
environment),  etc.  Nonetheless  the  order-of  analysis,  in  conjunction  with  the  fact  that  there  are 
U1  sequential  loops  in  the  relational  case,  does  give  an  indication  that  the  embedded  SQL  queries 
could  be  potentially  slow  relative  to  the  nested-relational  case.  This  rings  particularly  true  since 
for  each  of  the  10  queries,  there  is  a  separate  parsing,  optimization,  and  extraction.  In  addition, 
t  in1  (pteries  all  involve  a  multi-way  join. 

The  overall  conclusion  is  that  a  nested-relational  data  model  has  an  advantage  over  a  relational 
model  for  this  particular  application  (IDEFo),  and  the  particular  queries  considered  (drawing  data 
essential  data). 
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Recommendations 


Unfortunately,  this  research  effort  generated  more  questions  than  answers  Obviously  these 
questions  can  only  be  answered  through  additional  research. 

The  most  obvious  area  where  additional  work  needs  to  be  done  is  in  an  actual  nested-relational 
implementation  of  the  derived  design.  Given  a  robust  nested-relational  DBMS,  it  would  be  p<  .-.-ihle 
to  implement  both  a  relational  version  and  a  nested-relational  version  using  using  the  >ame  DBMS 
In  the  relational  case  one  would  simply  create  tables  that  only  have  atomic  valued  attributes. 
The  advantage  of  using  the  same  DBMS  is  that  the  confounding  influence  attributable  to  different 
machines,  algorithms,  data  structures,  etc.,  would  be  minimized.  Once  the  two  implementations 
are  in  place,  one  could  then  develop  a  set  of  database  instances/queries  from  which  statistically 
valid  conclusions  could  be  made  relative  to  run  times,  query  complexities,  size  of  the  database,  etc 

The  thesis  investigation  does  not  consider  either  the  relational  or  nested-relational  version  in 
terms  of  input  and  update.  This  area  needs  to  be  addressed. 

The  assumptions  as  to  number  of  disk  accesses  for  the  relational  versus  nested-relational 
versions  needs  to  be  empirically  studied. 

Chapter  2  discussed  several  commercially  available  DBMS  that  are  designed  explicitly  for  use 
w  ithin  a  CASE  tool  environment.  An  interesting  research  topic  might  be  io  see  if  one  of  these 
DBMS  more  appropriately  meets  the  needs  of  the  IDEFo  abstract  data  model.  In  addition,  chapter 
2  looks  at  some  efforts  to  integrate  CASE  tool  data  across  the  software  development  life  cycle. 
In  particular,  the  EDIF  standardized  file  interchange  solution,  and  the  ATIS  "generic  DBMS” 
'olution.  An  interesting  research  topic  might  be  to  map  the  IDEFo  data  requirements  into  one  of 
these  proposed  formats  in  order  to  allow  the  data  to  be  available  during  all  phases  of  the  software 
development  process. 

Another  potential  research  area  concerns  an  embedded  querv  language  interface  to  SAtool 
II  One  suggestion  is  to  build  an  Ingres-based  embedded  SQL  version  of  SAtool  II  The  interface 


should  be  as  modular  as  possible  such  that  the  nested-relational  SQL/N'F  version  could  be  plugged 
in  later.  Considering  that  SAtool  II  is  written  in  Ada,  this  modularization  should  be  possible. 

The  complexity  measures  developed  in  this  thesis  effort  did  not  include  all  of  the  SQL/NF 
syntax,  and  they  ignored  the  complexity  introduced  by  joins,  unions,  compound  predicates,  etc. 
An  interesting  research  effort  might  be  to  develop  some  metrics  by  which  the  complexity  of  var¬ 
ious  queries  can  be  compared.  Obviously  these  parametrically  based  metrics  would  haw  to  be 
statistically  validated  using  a  sample  from  some  population  of  queries. 
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Appendix  A.  Some  CASE  Tools  and  Vendors 


The  following  descriptions  represent  some  of  the  more  popular  CASE  tools  currently  on  the 
market.  It  by  no  means  is  an  exhaustive  list.  Nonetheless,  it  does  give  some  idea  as  to  the  variety 
of  different  products  and  vendors. 


Adagraph  Analytic  Science,  Arlington,  V/4  Combines  early  graphical  design  with  an  Ada  style 
PDL.  Users  can  define  graphics  idioms  for  tasks  and  subtasks,  and  then  insert  and  reuse  these 
idioms  in  their  designs.  The  tool  provides  general  idioms  for  recurring  tasks  such  as  buffering, 
monitoring,  data  movement  or  device  driving. 

Aris  Software  Systems  Design,  Claremont,  CA  Takes  an  analysis  result  from  the  Cadre  Teamwork 
tool  and  automatically  creates  a  first-cut  at  an  Ada  program  structure.  Working  from  dataflow 
diagrams,  Aris  also  does  a  preliminary  partitioning. 

Autocode  Integrated  Systems,  Santa  Clara,  C.-f  Developed  out  of  a  need  to  simulate  control  system 
operation.  Working  somewhat  like  chips,  Autocode  software  blocks  contain  prewritten  code. 
Each  block  performs  a  different  transformation  on  its  inputs.  The  user  basically  wires  the 
blocks  together  on  the  screen.  As  with  most  other  code  generators,  seme  of  the  code  must  he 
hand  written,  e  g.  .the  code  for  reading  of  inputs  and  posting  of  outputs  to  outside  hardware 

Byron  PDL  Intermetrics,  Cambridge,  MA  An  Ada  design  language  that  lets  the  user  add  key¬ 
words  and  comments  in  the  code  thus  making  it  possible  to  automatically  extract  DoD-STD- 
2167  documentation  from  the  annotated  code  v>a  the  Byron  Document  Generator. 

Designaid  Nastec.  Southfield,  MI  Based  upon  the  Ward  Mellor  methodology.  The  user  draws  the 
diagrams,  which  the  system  then  checks  to  ensure  that  the  connections  are  legal,  and  that 
the  data  items  have  been  defined  correctly.  All  verified  information  is  automatically  stored 
in  the  system  database. 

EPOS-S  Software  Products  and  Services,  New  York,  NY  Combines  graphics  and  PDL.  It  is  a 
design-oriented  formal  language  used  for  partitioning  the  software  design  and  for  more  detailed 
design  using  a  PDL.  Users  start  with  graphics  at  the  higher  levels,  and  then  switch  to  PDL 
at  the  lower  levels.  There  is  a  module  to  check  for  completeness,  consistency  and  module 
interconnection.  There  are  templates  for  DoD-STD-2167  documentation. 

Excelerator  Index  Technology,  Cambridge,  MA  Supports  both  Vourdon  DeMarco  and  Cane  Sar- 
son  systems  analysis  methods;  supports  Chen  or  Merise  entity-relationship  analysis  methods. 
With  this  tool,  users  can  develop  data  flow  diagrams  and  structure  charts.  The  tool  can  be 
used  to  develop  data  model  diagrams,  entity  relationship  diagrams.  It  allows  allows  the  user 
to  generate  presentation  graphics  to  present  the  overall  system  definition  to  users  and  man¬ 
agers.  All  information  is  kept  in  Excelerator's  data  dictionary,  which  is  one  of  Excelerator 's 
most  powerful  features.  Every  part  of  a  graph  can  be  described  to  the  central  project  database 
at  the  time  you  create  it.  This  "record-as-you-go”  feature  prevents  loss  or  unnecessary  du¬ 
plication  of  data.  Index  has  done  quite  well  with  it's  IBM-PC  based  version  of  Excelerator. 
It  is  probably  the  most  well  known  and  perhaps  the  most  capable  of  the  current  generation 
of  PC  based  CASE  tools. 

Popkin  Windows  System  Architect  Chelsea  Systems,  New  York,  AM’Supports  the  Ward  Mel¬ 
lor  methodology.  The  user  draws  diagrams,  the  system  checks  them  for  compliance  with  a 
set  of  rules,  and  stores  the  results  in  a  data  base 
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Proinod/RT  Promod,  Lake  Forest.  C.4  Based  on  the  Hatley  control-flow  and  state-transition 
diagrams.  The  user  draws  the  required  graphics  with  the  tool’s  graphics  editor,  and  then 
enters  control  specifications  et  al,  by  way  of  a  text  editor.  The  results  are  then  saved  in 
files.  The  tool  can  perform  an  automatic  provisional  design  partitioning  based  upon  these 
files  created  by  the  software  analysis. 

Ready  Taskbuilder  Ready  Systems,  Palo  Alto,  CA  Set  of  tools  based  on  Ward  Mcllor  method. 
Allows  users  to  develop  data-flow  diagram,  get  information  on  intertask  synchronization  and 
communication,  estimate  concurrent  execution  timing,  define  data  items,  data  types  and  Ada- 
style  software  packages,  lay  out  a  graphical  design,  and  then  proceed  to  write  program  design 
language  (PDL)  descriptions. 

Reverse  Engineering  Meta  Systems.  Ann  Arbor,  MI  Examines  code  or  data  dictionaries  and 
then  automatically  forms  a  logical  view  of  the  software.  Users  can  look  at  the  calling  structures 
of  the  code,  get  data  definitions  and  data  structures,  and  locate  dead  data  and  code. 

Software  Engineering  Workbench  Yourdon,  New  York.  NY  Based  on  Cadware's  Rule  Tool. 
Yourdon  has  added  its  own  icons  and  associated  rules  for  the  Ward  Mellor  real-time  systems 
method,  global  checking,  and  its  own  data  dictionary 

Statemate  iLogix.  Burlingtom,  MA  Interesting  tool  in  that  it  can  execute  real-time  soft  ware  spec¬ 
ifications.  The  simulation  can  be  for  the  entire  system  or  any  syntactically  complete  portion 
of  the  system  considered  in  isolation.  The  system  can  also  generate  DoD-STD-2 167  docu¬ 
mentation  for  use  by  companies  developing  software  under  DoD  contracts. 

Structured  Architect-Real  Time  Meta  Systems,  Ann  Arbor.  MI  Implements  the  Ward  Mellor 
software-analysis  methods.  This  tool  generates  the  required  graphics  including  data-flow, 
data-control,  and  state-transition  diagrams,  and  state  transition  matrices.  Users  also  create 
structured  lists  and  data  base  entries.  This  material  is  used  by  SA-RT  to  automatically  enter 
information  into  a  data  base. 

SuperCASE  Advanced  Technology  International,  New  York,  NY  Prompts  the  user  to  name  the 
Ada-like  subsystems  and  packages.  That  information  is  used  to  generate  subsystem,  package 
and  task  template  specifications — all  of  which  can  be  customized  or  used  as  is.  Then  the 
designer  moves  on  to  templates  for  package,  subpackage  and  task  bodies,  writing  and  editing 
them  in  PDL  on  the  screen-displayed  templates. 

Tags  Teledyne  Brown  Engineering,  Fairfax,  VA  A  requirements  language  to  express  software  spec¬ 
ifications.  It  uses  blocks  and  icons  to  create  timing  and  flow  diagrams.  These  specifications 
can  be  checked  to  uncover  static  errors  and  then  executed  to  simulate  the  real-time  operation 
of  the  software  being  modeled.  The  executable  code  generated  from  the  description  is  in  the 
Ada  language,  but  is  for  use  only  in  this  kind  of  dynamic  checking,  not  in  the  final  system. 

TekCASE  Designer  Tektronix,  Beaverton,  OR  Tool  set  which  implements  the  Ward  Mellor  or 
Hatley  method  for  system  software  analysis.  It  merges  real-time  software  specification  dia¬ 
grams  into  a  single  diagram  and  produces  an  editable  provisional  partitioning,  for  software 
design.  A  listing  and  evaluation  routine  reports  on  inconsistencies,  problem  areas  and  de¬ 
viations  from  defined  structured  design  methods.  TekCASE  does  not.  do  automatic  code 
generation,  but  the  output  of  the  listing  routine  can  be  edited  into  code  stubs  for  the  lan¬ 
guage  being  used.  Once  the  source  code  is  completed,  a  TekCASE  Designer  routine  can 
convert  it  into  structure  charts,  compare  the  charts  with  the  final  design  and  report  on  any 
differences. 

Toolkit  Cadre  Group,  New  Haven,  CTCan  be  adapted  to  a  several  popular  diagramming  methods. 
The  user  selects  icons  with  the  mouse  or  keyboard  and  uses  them  to  draw  the  diagrams.  If 
a  use-rule  is  violated,  a  circled  X  appears  over  the  affected  item  and  an  error  message  is 
displayed.  Another  routine  automatically  enters  information  into  a  database  from  information 
drawn  on  the  screen.  The  Verify  routine  detects  any  global  violations  of  rules,  particularly 
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those  violations  that  couldn't  be  checked  during  the  drawing  process.  There's  also  a  tool 
(Cad ware  Rule  Tool)  that  lets  users  modify  existing  analysis  methods  or  set  up  their  own 
methods  for  creating  software  diagrams 
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Appendix  B.  IDEFq  Language  Features 


Ross  defines  40  features  of  his  Structured  Analysis  language,  which  "constitute  the  basic  core 
of  the  language  for  communication”  (30:19).  Unfortunately,  the  IDEF0  user's  manual  does  not 
include  a  single  summary  of  the  IDEFo  language  as  does  Ross's  paper.  However,  during  his  thesis 
effort ,  Johnson  extracted  the  IDEFo  subset  from  the  user's  manual  and  cross  referenced  it  to  the 
appropriate  SA  feature.  The  following  table  is  adapted  from  Johnson’s  work: 


Table  14.  IDEFp  Language  Features 


SA  Item  No. 

Name 

1 

box 

2 

arrow 

3 

input 

3 

output 

4 

control 

5 

mechanism 

6 

activity  name 

7 

label 

12 

branch 

13 

join 

14 

bundle 

15 

spread 

18 

boundary  arrow 

20 

detailed  reference  expression 

22 

2- way  arrow 

24 

tunnel  arrow 

25 

to/from  all 

27 

footnote 

28 

metanote 

29 

squiggle 

30 

c-number 

31 

node  number 

32 

model  name 

33 

1COM  code 

37 

facing  page  text 

38 

for  exposition  only 

39 

glossary 

40 

node  index 

( 19:A-3) 
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Appendix  C.  SAtool  Product * 


The  following  pages  present  some  typical  examples  of  the  current  SAtool  products,  as  illus¬ 
trated  in  Figure  20.  Recognize  that  the  new  Ada  version,  built  by  Smith,  may  have  a  slightly 
different  format  (35). 


Figure  20.  SAtool  Products 

Typical  SAtool  IDEFo  Drawing  Outputs 

The  following  two  drawings  are  typical  those  produced  by  SAtool.  Figure  21  represents  the 
so  called  "A  minus  zero”  diagram,  which  is  basically  the  context  diagram,  and  Figure  22  represents 
the  first  level  decomposition,  the  “A  zero”  diagram. 
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AUTHOR  Gerald  R  Morris 


DATE  14Feb89 


READER 


PROJECT  DM  Example 


REV  1  0 


DATE 


□ 


an  example  decomposition 
not  completed 


NODE 

A-0 


TITLE  DM  Example 


NUMBER  l 


Figure  21.  Typical  A-0  Diagram 
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Figure  22.  Typical  AO  Diagram 
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Data  Dictionary  Outputs 


The  following  two  listings  are  representative  of  an  activity  data  dictionary  SAtool  product, 
and  a  data  element  data  dictionary  product. 


ACTIVITY  Data  Dictionary. 


I 

NAME  : manage  numeric  data 

TYPE  : ACTIVITY 

PROJECT  :DM  Example 

NUMBER  :A1 

DESCRIPTION 

This  activity  will 

handle  numbers 

INPUTS 

unumber 
errors 
OUTPUTS  : 

numbermsgs 

CONTROLS 

numberrules 
MECHANISMS  : 

ALIASES  : 

COMMENT  : 

PARENT  ACTIVITY  : manage  database 
REFERENCE: 

KNR  N00028-89-0123  3.3.2.1.2a 
REF  TYPE: 
contract 
VERSION  : 1 . 0 
VERSION  CHANGES  : 

DATE  : 14Feb89 

AUTHOR  : Gerald  R.  Morris 
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DATA  ELEMENT  Data  Dictionary. 


\ 

NAME  unumber 

TYPE  DATA  ELEMENT 

PROJECT  :DM  Example 

DESCRIPTION  :This  is  the  user  numeric  data 
DATA  TYPE  : integer 
MIN  VALUE  : 

MAX  VALUE  : 

RANGE  : integer 'range 
VALUES 

PART  OF  :userdata 
COMPOSITION 
ALIASES 
WHERE  USED 
COMMENT  : 

SOURCES 

DESTINATIONS 

INPUT: 

manage  numeric  data 
REFERENCE: 

AFM  35-10  page  3  para.  2.3 
REF  TYPE: 

AFM 

VERSION  : 1 .0 
VERSION  CHANGES  : 

DATE  : 14Feb89 

AUTHOR  : Gerald  R.  Morris 
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Appendix  D.  Analysis  Phase  Data  Base 


Tlie  AFIT  System  Development  Guidelines  specify  the  two  types  of  items  that  belong  in  an 
analysis  phase  data  dictionary  -  activities,  and  data  elements  (10:8).  As  seen  in  the  last  chapter, 
the  SAtool  output  products  include  an  ascii  text  data  dictionary  file  which  can  be  imported  to 
the  heterogeneous  database  via  Connally's  Data  Manager  (9).  The  following  pages  illustrate  the 
relations  for  the  analysis  phase  portion  of  Connally's  heterogeneous  database. 
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Appendix  E.  Typical  Data  Manager  Session 


As  mentioned  in  the  previous  chapter,  C'onnally  included  a  Data  Manager  which  allows  the 
data  dictionary  files  to  be  uploaded  into  his  heterogeneous  database.  Here  is  atypical  Data  Manager 
session: 


ssc(l)>  dm 

DATA  HAIAGER  EXECUTIOI  HEIU 

1.  Build  nee  transaction  file  for  execution. 

2.  Use  existing  transaction  file  for  execution. 

3.  Exit 

EITER  CHOICE:  1 

Please  enter  the  transaction  file  name:  jerry 

DATA  HAIAGER 
TRAISACTIOI  RECORD  MEIU 

TOOL  SELECTIOV 

1 .  Sun  SADT  Editor 

2.  Data  Dictionary  Editor 

EITER  CHOICE: [1] 

DATABASE  IAHE : [  jerry . — ] 

SESSIOI  OUIER  IAHE:  [DATA  HAIAGER . ] 

TRAISACTIOI  IIDICATOR  SELECTIOW 

1 .  RETRIEVE  DATA 

2.  RETRIEVE  DATA  FOR  UPDATE 

3.  WRITE  IEV  DATA 

4 .  WRITE  UPDATED  DATA 

S .  DELETE 

6.  ABORT  SESSIOI 

7.  EXIT  TRAISACTIOI  HEIU 

EITER  CHOICE: [3] 

SESSIOI  FILE  IAHE :  [dma.O - - ] 

PROJECT:  [DH  Example—] 

TYPE  SELECTION 
1 .  ACTIVITY 
2  DATA  ITEH 

3.  BOTH 
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EITER  CHOICE: [3] 


SUCCESSFUL  BUILD  OF  TRAISACTIOI  FILE 


TYPE  OF  EIECUTIOI 

1  Background  (Terminal  available  during  execution) 

2.  Foreground  (Terminal  unavailable  during  execution) 

3.  Exit 


Enter  Choice :  2 
Data  Manager  non  executing 

Please  be  patient,  screen  may  be  blank  for  up  to  30  seconds. 
Possibly  longer  for  PAREIT/LEVEL  transactions. 


DATA  HA1AGER  TRAISACTIOI  RESULTS 


TRAISACTIOI  FILE  IAME:  jerry . ins 

TOOL  IAME:  SADT 

SESSIOI  OWIER:  DATA  MAIAGER 

DATABASE  IAME:  jerry 

PHASE:  REQ 

TYPE:  BOTH 

PROJECT  IAME:  DM  Example 

TYPE  OF  TRAISACTIOI:  WRITE  —  ALL  IEW  RECORDS 
Updates  performed  using  file:  dma_0  dbs 


EITITIES  LISTED  TO  BE  UPDATED 

manage  database  ACT  W 
feedback  OBJ  W 

userdata  OBJ  W 

rules  OBJ  W 

RESULTS  OF  THE  UPDATE 


manage  database 
feedback  OBJ 
userdata  OBJ 
rules  OBJ  W 


ACT  W  successful  update 
W  successful  update 
W  successful  update 
successful  update 


SUCCESSFUL  UPDATE 


ssc ( 2 )  > 


no 


Appendix  F.  Example  IDEFq  Relational  Database  Instance 


The  relational  database  instance  shown  below  corresponds  to  the  diagrams  shown  in  Figure  7. 
and  Figure  8.  The  example  was  constructed  manually  using  a  plain  text  editor,  and  was  used  to 
do  the  stepwise  refinement  of  the  relational  design.  Note  that  some  of  the  data  m  the  example 
database  is  in  symbolic  form,  e  g.,  the  locations  of  the  various  components.  In  addition,  recall 
that  the  IDEFq  diagrams  only  show  drawing  data.  For  example,  the  label  "error  codes"  on  the  AO 
diagram  actually  corresponds  to  the  data  element  "errors"  as  can  be  determined  via  the  data21abel 
relation.  In  short,  the  essential  data  below  is  being  shown  for  the  first  time. 


act2act 

parent.node  child. node 
1  2 

1  3 

act2data 
node. id  data. id 
1  t 

1  2 

1  3 

2  4 

2  11 

3  5 

3  11 

2  6 

3  7 

2  8 

3  9 

3  10 

act2hist 

node.id  hiat.id 
3  1 

act2ref 

node. id  ref.if 
1  1 

1  2 

2  6 

3  7 

act.descr 
node.id  line.no  deac.line 

1  1  This  is  the  context  diagram 

1  2  for  the  data  manager  analysis 

2  1  This  actieity  eill 

2  2  handle  numbers 

3  1  This  actieity  eill 

3  2  handle  alphanumerics 


icom.type 

I 

C 

a 

i 

i 

i 

i 

c 

c 

o 

o 

H 
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act ivity 
node.id 

(part  1) 

nod*  nan* 

project. id  author. id 

1 

10  manage 

database  1 

1 

2 

A1  manage 

numeric  data  1 

1 

3 

12  manage 

alpha  data  1 

1 

act ivity 

version 

(part  2) 
date  x 

y  eisible.DRE 

sheet. id 

1  .0 

02/14/89  1 

1  -1 

1 

1  0 

02/14/89  16 

16  0 

2 

1.0 

02/14/89  17 

17  0 

2 

analyst 

author_id  author 

1 

Gerald  R.  Norris 

arrow 


symbol. id 

arrow. typi 

2 

3 

4 

1 

6 

3 

10 

3 

14 

3 

18 

1 

22 

1 

24 

3 

36 

1 

41 

3 

42 

3 

43 

3 

boundary 

symbol_id 

icom.code 

7 

11 

15 

Cl 

23 

01 

data2data 

parent.data  child.di 

i 

4 

i 

5 

2 

6 

2 

7 

3 

8 

3 

9 

dat a21abel 
data.id  label. id 


1 

2 

3 
1 

4 

5 
2 

6 
7 
3 
3 

9 

10 
11 
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4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 
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! 


data2ref 


data.id 

1 

2 

3 

4 

5 

6 

7 

8 
9 


raf .id 

3 

4 

5 
8 
9 

10 

11 

12 

13 


data2value 
data.id  value. id 
11  1 

11  2 


data.descr 
data.id  line.no 


1  1 

1  2 

2  1 

2  2 

3  1 

3  2 

4  1 

5  1 

6  1 

7  1 

8  1 

9  1 

10  1 


desc.line 
This  is  the  user 
input  data 
This  is  the 
database  rules 
This  is  the 
user  feedback 

This  is  the  user  numeric  data 
The  users  alphanumeric  data 
Rules  for  numeric  data 
Rules  for  alphanumeric  data 
Feedback  for  numeric  data 
Feedback  for  alphanumeric  data 
See  Flight  Control  lode  413 


data.elem 


data. id 

name 

project.id 

author. id 

version 

data 

1 

userdata 

1 

1 

1.0 

02/14/89 

2 

rules 

1 

1 

1.0 

02/14/89 

3 

feedback 

1 

1 

1 .0 

02/14/89 

4 

unumber 

1 

1 

1 .0 

02/14/89 

S 

ualpha 

1 

1 

1  .0 

02/14/89 

6 

numberrules 

1 

1 

1.0 

02/14/89 

7 

alpharules 

1 

1 

1  .0 

02/14/89 

8 

numbermsgs 

1 

1 

1.0 

02/14/89 

9 

alphamsgs 

1 

1 

1.0 

02/14/89 

10 

alphacall 

1 

1 

1 .0 

02/15/89 

11 

errors 

1 

1 

1.0 

02/17/89 

data.type 
data.id  type 

4  integer 

5  ascii 

11  errcode 


data. range 

data.id  data. range 

4  integer ’range 

5  ascii ’range 

data.value 
value.id  value 

1  bad  input 

2  bad  output 
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footnote 
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t  90  90 

graphics 
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hist.id  hist.proj 
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10 

feedback 
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numbermsgs 
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13 
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14 

error  codes 

85 
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note 
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1  1  11  U 

note. text 
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project 

project. id  name 

I  DN  Example 

ref. type 

ref. id  ref. type 

1  military  standard 

2  std  operating  procedure 

3  military  standard 

4  military  standard 

5  military  standard 

6  contract 

7  contract 

8  A  Fit 

9  A  Fit 

10  AFH 

II  AFH 

12  AFH 

13  AFH 


text. line 

an  example  decomposition 
not  completed 
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reference 

ref.id  lina.no  ref.line 
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1 

MIL-Std-00091 
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2 

page  3 

para 

7-5 
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1 

System  Development  Guide 

2 
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Draft  4 

2 

3 

chap  2 
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1 

MIL-Std 
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2a 
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2a 
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10  page  3 
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9 

l 
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10  page  3 
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10 

1 
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10  page  4 
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11 
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33 

33 
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15 
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41 
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symbol. id 
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41 
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Appendix  G.  SQL  Scripts 


This  appendix  includes  the  SQL  scripts  used  to  create  the  relational  tables,  perform  a  bulk 
load,  and  bulk  erase  of  t he  relational  database,  show  the  contents  of  all  the  relational  tables,  and 
extract  drawing  and  essential  data. 

Create  Tables 

The  following  SQL  script  creates  the  relations  for  the  Ingres  relational  implementation  of  the 
IDEFo  database. 


CREATE  TABLE  act2act  ( 

parent. node  integer*. 


child.node 

integer*) ; 

CREATE  TABLE 

act2data  ( 

node.id 

integer* , 

data. id 

integer* , 

icom.type 

cl), 

CREATE  TABLE 

act2hist  ( 

node.id 

integer* , 

hist. id 

integer*) ; 

CREATE  TABLE 

act2ref  ( 

node. id 

integer* , 

ref. id 

integer*)  ; 

CREATE  TABLE 

activity  ( 

node.id 

integer* , 

node 

c20. 

name 

c25  , 

pro ject.id 

integer*. 

author. id 

integer2. 

version 

clO, 

date 

cB, 

z 

integer2 , 

T 

integer2 , 

visible. ORE 

integerl , 

sheet. id 

integer*) ; 

CREATE  TABLE 

act. changes 

( 

node.id 

integer* , 

changes 

c60) ; 

CREATE  TABLE 

act.descr  ( 

node.id 

integer*. 

line.no 

integer2 , 

desc.line 

c60)  ; 

CREATE  TABLE 

alias  ( 

data. id 

integer*. 

naae 

c2S , 

share. used 

c2S , 

coament 

c25) ; 
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CREATE  TABLE  Analyst  ( 

author.id 

integer2 , 

author 

c20) ; 

CREATE  TABLE  arros  ( 

symbol.id 

intagar4 , 

arrow. typa 

intagarl) 

CREATE  TABLE  boundary  ( 

symbol. id 

integar4. 

icom.coda 

c2) ; 

CREATE  TABLE  data2data  ( 

parent .data  integer4. 

child. data 

intagar4) 

CREATE  TABLE  data21abel 

( 

data.id 

intagar4 , 

labal.id 

intagar4) 

CREATE  TABLE  data2raf  < 

data.id 

intagar4 , 

raf.id 

intagar4) 

CREATE  TABLE  data2talue 

( 

data.id 

intagar4 , 

value. id 

intagar4) 

CREATE  TABLE  data. changes  ( 

data.id 

integar4 , 

changas 

c60) ; 

CREATE  TABLE  data.dascr  ( 

data.id 

intagar4 , 

lina.no 

intagar2 , 

daac.lina 

c60)  ; 

CREATE  TABLE  data.alaa  ( 

data.id 

integer* , 

naaa 

C25, 

project.id 

int agar4 , 

author. id 

intagar2 , 

torsion 

CIO, 

data 

c8)  ; 

CREATE  TABLE  data.ranga  < 

data.id 

int agar4 , 

data.ranga 

c60) , 

CREATE  TABLE  data.typa  ( 

data.id 

intagar4 , 

typa 

c2S)  ; 

CREATE  TABLE  data. value 

value. id 

intagar4 , 

value 

clS)  ; 

CREATE  TABLE  dot  ( 

symbol. id 

intagar4. 

dot. typa 

intagarl) ; 

CREATE  TABLE  too  ( 

graf.id 

integer4, 

picture 

c60) ; 

CREATE  TABLE  footnote  ( 

graf.id 

intagar4 , 

X 

intagar2 , 

y  integer2) ; 

CREATE  TABLE  graphics  ( 

graf.id 

intagar4, 

shaat.id 

intagar4) ; 

CREATE  TABLE  hist. call  ( 

hist. id 

integer4 , 

hist. pro j 

C12, 

hist. nods 

C20)  ; 
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I. O'i'i  Database 


l'he  following  SQL  script  performs  a  bulk  load  of  the  data  in  the  example  database  into  ; he 


linr^s  relational  implementation  of  the  IDEFo  database. 


COPY  TABLE  act2act(parent.node«cO,child_node«cO) 

FROM  "DUAl : [NROTH . GNORRIS . IEVIDEFO] act2act . dat" ; 

COPY  TABLE  act2data(node_id«cO,data.id»cO , icom_type«cO) 

FROM  "DUA1 : [NROTH  GNORRIS . IEVIDEFO] act2dat a  dat" ; 

COPY  TABLE  act2ref (node.id«cO,ref_id«cO) 

FROM  "DUA1 : [NROTB . GNORRIS . IEVIDEFO] act2ref . dat" ; 

COPY  TABLE  act2hist(node.idacO,hist.id*cO) 

FRON  "DUA1 : [NROTH . GNORRIS . IEVIDEFO] act2hist . dat" ; 

COPY  TABLE  act ivity(node_ id»cO ,node«cO ,name»cO .pro ject _id*cO, 
author. id«cO ,version«cO ,date»cO,x»cO , y»cO .visible. DRE»cO , sheet _id«cO) 
FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFO] activity.dat" ; 

COPY  TABLE  act_descr(node_id»cO,line_no»cO ,desc.line«cO) 

FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFO] act .descr . dat " ; 

COPY  TABLE  analyst(author_idacO,author«cO) 

FRON  "DUA1 : [NROTH . GNORRIS . IEVIDEFO] analyst . dat" ; 

COPY  TABLE  arros(symbol.id«cO ,arros_type«cO) 

FRON  "DUA1 : [NROTH . GNORRIS . IEVIDEFO] arros . dat" , 

COPY  TABLE  boundary (synbol_id*cO , ico«_code»cO) 

FRON  "DUAl : [NROTH  GNORRIS . IEVIDEFO]boundary  dat" ; 

COPY  TABLE  data2data(parent.data»cO,child.data«cO) 

FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFO] data2dat a . dat" ; 

COPY  TABLE  data21abel(data.id>cO, label. id«cO) 

FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFO]data21abel . dat" ; 

COPY  TABLE  data2ref <data.id«cO,raf_id«cO) 

FRON  "DUAl : [NROTH .GNORRIS  IEVIDEFOjdata2ref.dat" ; 

COPY  TABLE  data2value(data_id>cO,value.id>cO) 

FRON  "DUAl : [NROTH .GNORRIS . IEVIDEFO] dat a2 value  dat” ; 

COPY  TABLE  data.descr(data_id>cO,line_no*cO ,desc.line>cO) 

FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFOldata.descr.dat" ; 

COPY  TABLE  dat a.eleaCdat a. id»cO ,naae«cO .pro ject.id»cO , author. id»cO, 
vers ion«cO, dat e»cO)  FRON  "DUAl : [NROTH  GNORRIS . IEVIDEFO] dat a. e lea . dat" ; 
COPY  TABLE  data_type(data_id>cO,type>cO) 

FRON  "DUAl: [NROTH. GNORRIS. IEVIDEFO] data. typedat"; 

COPY  TABLE  data_ranga(data_id>cO ,data.range»cO) 

FRON  "DUAl : [NROTH  GNORRIS . IEVIDEFO] dat a. range .dat" ; 

COPY  TABLE  data_value(value.idacO,value>cO) 

FRON  "DUAl : [NROTH  GNORRIS . IEVIDEFO] data.value . dat" ; 

COPY  TABLE  footnote(graf.id*cO,x»cO,y«cO) 

FRON  "DUAl : [NROTH  GNORRIS . IEVIDEFO] footnote . dat" ; 

COPY  TABLE  graphics (graf.idecO, sheet. id*cO) 

FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFO] graphics .dat" ; 

COPY  TABLE  hist. callChist.idecO, hist. proj»cO, hist. node»cO) 

FRON  "DUAl: [NROTH.GNORRI3.IEVIDEFOjhist.call.dat"; 

COPY  TABLE  label(label_idacO,naaaacO , x»cO, y«cO, sheet. id»cO) 

FRON  "DUAl : [NROTH  GNORRIS  IEVIDEFO]label  dat"; 

COPY  TABLE  note(graT.id«cO,label«cO,x»cO,y*cO) 

FRON  "DUAl : [NROTH  GNORRIS . IEVIDEFO]note  dat" ; 

COPY  TABLE  note. text  <gral.id»eO  .line. no«cO  ,  text _lme«cO) 

FRON  "DUAl : [NROTH . GNORRIS . IEVIDEFO] note. text . dat" , 

COPY  TABLE  pro ject (pro ject.id»cO ,n»*e«cO) 

FRON  "DUAl : (NROTH  GNORRIS . IEVIDEFO] project  dat"; 

COPY  TABLE  reference(ref_idacO, lias. no>cO, ref .line»cO) 

FRON  "DUAl : (NROTH .GNORRIS . IEVIDEFO] reference . dat”; 
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COPY  TABLE  ref .typetref .id»cO ,ref.type»cO) 

FROM  "DUA1 : [MROTH  .GHORRIS . IEVIDEFO] ref. type  dat" ; 

COPY  TABLE  segment (seg_id»cO ,data_id«cO , sheet _id»cO ,xs*cO ,ys=cO ,xe«cO , ye=cO) 
FROM  "DUA1 : [MROTH  GHORRIS . IEVIDEFO] segment  dat"; 

COPY  TABLE  sheet(sheet_id»cO,c_number-cO) 

FROM  "DUA1 : [MROTH  GHORRIS . IEVIDEFO] sheet .dat" ; 

COPY  TABLE  squiggle (graf_id=cO,xl=cO ,yl=cO ,x2=cO ,y2=cO, 
x3=c0 , y3»cO , x4=cO , y4»c0) 

FROM  "DUA1 : [MROTH . GHORRIS . IEVIDEFO] squiggle .dat" ; 

COPY  TABLE  symbol < symbol. id«cO,seg_id»cO .sheet. id»cO, x=cO ,y»cO) 

FROM  "DUA1 : [MROTH . GHORRIS . IEVIDEFO] symbol . dat" ; 

COPY  TABLE  to.from.all(symbol.id»cO,tfa.label»cO> 

FROM  "DUA1 ; [MROTH  GHORRIS . IEVIDEFO] to.from.all .dat" ; 

COPY  TABLE  tunnel(symbol.id>cO,tunnel_typeacO) 

FROM  "DUA1: [MROTH . GHORRIS . IEVIDEFO] tunnel .dat" ; 

COPY  TABLE  turn(symbol_id«cO,turn_type“cO) 

FROM  "DUA1 :  [MROTH . GHORRIS  .  IEVIDEFO]  turn .  dat •• ; 


Erase  Database 


The  following  SQL  script  eliminates  all  the  data  in  the  Ingres  relational  implementation  of 
the  IDEFq  database. 


DELETE  FROM  act2act; 
DELETE  FROM  act2data; 
DELETE  FROM  act2hist ; 
DELETE  FROM  act2ref; 
DELETE  FROM  activity; 
DELETE  FROM  act.changes; 
DELETE  FROM  act.descr; 
DELETE  FROM  alias; 

DELETE  FROM  analyst; 
DELETE  FROM  arros; 

DELETE  FROM  boundary; 
DELETE  FROM  data2data; 
DELETE  FROM  data21abel; 
DELETE  FROM  data2ref; 
DELETE  FROM  data2»alue; 
DELETE  FROM  data.changes ; 
DELETE  FROM  data.descr; 
DELETE  FROM  data. elan; 
DELETE  FROM  data. range; 
DELETE  FROM  data.type; 
DELETE  FROM  data.value; 
DELETE  FROM  dot; 

DELETE  FROM  feo; 

DELETE  FROM  footnote; 
DELETE  FROM  graphics; 
DELETE  FROM  hist. call; 
DELETE  FROM  label; 

DELETE  FROM  min.aax; 
DELETE  FROM  note; 

DELETE  FROM  note.text; 
DELETE  FROM  project; 
DELETE  FROM  reference; 
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DELETE  FROM  rsf.typs; 
DELETE  FROH  segment ; 
DELETE  FROH  shsst; 

DELETE  FROH  squiggls; 
DELETE  FROH  symbol; 
DELETE  FROH  to.froa.all; 
DELETE  FROH  tunnel; 
DELETE  FROH  torn; 


Show  Database 


The  following  SQL  script  shows  all  the  data  in  the  Ingres  relational  implementation  of  the 
IDEFq  database. 


SELECT 

FROH  act2act; 

SELECT 

FROH 

act2data; 

SELECT 

FROH 

act2hist ; 

SELECT 

FROH 

act2r«f ; 

SELECT 

FROH 

activity; 

SELECT 

FROH 

act. changes; 

SELECT 

FROH 

act.descr ; 

SELECT 

FROH 

alias ; 

SELECT 

FROH 

analyst ; 

SELECT 

FROH 

arrow ; 

SELECT 

FROH 

boundary ; 

SELECT 

FROH 

data2data; 

SELECT 

FROH 

data21ab«l ; 

SELECT 

FROH 

data2r«f ; 

SELECT 

FROH 

data2valu« ; 

SELECT 

FROH 

data.changes 

SELECT 

FROH 

data.descr ; 

SELECT 

FROH 

data.elea; 

SELECT 

FROH 

data. rang* ; 

SELECT 

FROH 

data.typs; 

SELECT 

FROH 

data. valus ; 

SELECT 

FROH 

dot ; 

SELECT 

FROH 

fso; 

SELECT 

FROH 

footnote ; 

SELECT 

FROH 

graphics ; 

SELECT 

FROH 

hist. call; 

SELECT 

FROH 

labsl; 

SELECT 

FROH 

ain.aax ; 

SELECT 

FROH 

nota; 

SELECT 

FROH 

noto.tsxt ; 

SELECT 

FROH 

projsct ; 

SELECT 

FROH 

reference; 

SELECT 

FROH 

rsf.typs; 

SELECT 

FROH 

ssgasnt ; 

SELECT 

FROH 

shsst ; 

SELECT 

FROH 

squiggls; 

SELECT 

FROH 

symbol ; 

SELECT 

FROH 

to.froa.all ; 

SELECT 

FROH 

tunnsl ; 

SELECT 

FROH 

turn ; 
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Extract  Drawing  Data 


The  following  queries  extract  drawing  data  from  the  Ingres  DBMS  implementation  of  the 
IDEF0  database.  The  first  set  of  queries  complete  the  drawing  that  was  started  m  Chapter  .  the 
second  set  of  queries  extract  the  data  to  draw  the  AO  diagram  depicted  in  Figure  S. 

A-0  Drawing  Data  The  queries  in  this  section  complete  the  extraction  of  drawing  data  for 
the  A-0  diagram  depicted  in  Figure  7,  that  was  started  in  Chapter  3.  Recall  the  partially  completed 
drawing  so  far  consists  of  the  sheet  headers,  all  boxes,  and  all  line  segments 

This  set  of  queries  extract  all  the  symbols  for  the  ends  of  the  segments.  I  lie  s_\  mbols  extracted 
are  arrows,  turns,  tunnels,  and  to-from.alls.  In  some  instances,  e  g.,  tunnels,  there  are  no  tuples 
extracted  because  there  are  none  of  that  type  of  symbol.  Associated  with  each  symbol  is  its  location, 
and  a  discriminator  which  indicates  the  type  ,  e.g.,  down  arrow  =  1,  or,  in  the  case  of  to-from-all, 
a  label. 


select  sy.x,  ij.f,  ar.arro8_.type 
from  symbol  sy,  arros  ar 
where  ar. symbol. id  »  sy . symbol.id  and 
sy  sheet. id  in  ( 
select  a. sheet. id 
from  project  p, activity  a 
where  p. project. id  *  a. project. id  and 


a  .  node  * 

"10' 

and 

p  .naa*  ■ 

"DH  Example 

!*  It 

arrov. 1 

1 

1  41 

4 

31 

1  71 

7 

11 

1  101 

10 

31 

. 1 

select  sy.x,  sy.y,  tu. turn. type 
from  symbol  sy,  turn  tu 
where  tu. symbol. id  »  sy. symbol. id  and 
sy  sheet, id  in  ( 
select  a. sheet. id 
from  project  p, activity  a 
where  p. project. id  •  a. project. id  and 
a. node  ■  "40"  and 
p  name  »  "DM  Example"); 
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Figure  23.  A-0  Diagram  (partial  drawing  31 


lx  ly  I  turn. 1 1 

I . I 

I . I 

select  sy.x,  ay  .  y ,  tu  tunnel.type 
from  symbol  sy,  tunnel  tu 
where  tu. symbol. id  »  sy. symbol. id  and 
sy  sheet. id  in  ( 
select  a.aheet.id 
from  project  p, activity  a 
where  p. project. id  »  a. project. id  and 
a  node  »  "AO"  and 
p  name  »  "OH  Example"); 

lx  ly  I  tunnel  I 

I— . I 


At  this  point  the  drawing  tool  adds  the  symbols  to  the  drawing.  The  updated  partial  drawi 
that  results  from  adding  these  symbols  is  shown  in  Figure  23 
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This  next  query  extracts  the  tuples  corresponding  to  the  labels  associated  with  the  data 


elements  (arrows). 


select  1 . x , 1 . y ,1 . name 

from  label  1 

where  1. sheet. id  in  ( 


select  a 

. sheet. id 

from  project  p, activity  a 

where  p. 

project.id  »  a. project 

a  node  * 

"AO"  and 

p . name  * 

"DM  Example"); 

it 

I  name  | 

21 

2|userdata  1 

51 

SI  rules  1 

81 

8 1  feedback  1 

The  drawing  tool  now  adds  the  labels  at  the  specified  (x.y)  locations  resulting  in  the  partial 
drawing  shown  in  Figure  24. 

These  next  queries  extract  the  data  associated  with  the  other  graphical  constructs,  i.e..  squig- 
gles.  and  footnotes.  Note  there  are  two  set  of  ordered  pairs  associated  with  the  footnote  The  first 
pair  is  the  location  of  the  label  marker,  and  the  second  is  the  location  of  the  actual  footnote  text. 


select  111,  s.yl,  s.x2,  s.y2,  s.x3,  s.y3,  3x4,  s.y4 
from  squiggle  s,  graphics  g 
where  s.graf.id  *  g.graf.id  and 
g. sheet. id  in  ( 
select  a. sheet. id 
from  project  p, activity  a 
where  p. project. id  *  a. project. id  and 
a. node  »  "40"  and 
p  name  >  "DM  Example"); 
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Figure  24.  A-0  Diagram  (partial  drawing  4) 


selact  rmark«nx,  j»«rk*n  j,  n. label,  xtaxt>f.x,  ytsxt*f.y, 
nt.lina.no,  nt.taxt.lina 

from  note  n,  nota.taxt  nt ,  footnota  f,  graphics  g 
whera  n.graf.id  »  g.graf.id  and 
f  graf.id  «  g.graf.id  and 
nt  graf.id  ■  g.graf.id  and 
g . shaat.id  in  ( 
salact  a. shaat.id 
from  projact  p, activity  a 
uhara  p.projact.id  »  a. projact. id  and 
a  noda  •  "10"  and 
p  nama  ■  "DH  Exampla"); 

I xmark  I  ymark  I labal  Ixtaxt  lytaxt  I  lina.nl taxt.lina 

I . - 

I  11!  llll  I  901  901  1 1  an  axampla  dacorapos it  ion  I 

I  111  llll  I  901  901  2 1  not  complatad  I 


At  this  point,  the  drawing  tool  can  add  the  footnote,  and  squiggle,  which  results  in  the 
completed  diagram  as  previously  seen  in  Figure  7. 


12(3 


AO  Drawing  Data.  These  next  queries  illustrate  the  extraction  of  the  drawing  data  associated 
with  the  AO  diagram.  As  before,  a  drawing  tool  might  require  the  user  to  supply  the  name  of  the 
project  being  drawn,  and  perhaps  the  desired  node.  Accordingly,  the  queries  shown  below  have 
"DM  Example”  as  the  project  name,  and  "AO”  as  the  desired  node. 

The  first  query  extracts  the  data  required  to  begin  drawing  the  AO  diagram  illustrated  in 
Figure  8.  As  in  the  previous  section,  the  table  immediately  following  the  query  contains  the  tuples 
that  are  extracted  as  a  result  of  the  query. 


select  a. name,  a. date,  an. author,  a. version,  s.c. number 
from  activity  a,  analyst  an,  sheet  s 
where  a. node  a  "10"  and 
a  author. id  »  an. author. id  and 
s.sheet.id  •  a.sheet.id  and 
a . pro ject.id  in  ( 
select  p. project. id 
from  project  p 

where  p.name  «  "DH  Example"); 

I  name  I  date  I  author  I  version  I c. number  I 

I . I 

I  manage  database  l02/14/89IGerald  R.  Morris  ll.O  I  ll 

I . - . I 


At  this  point,  the  drawing  tool  can  draw  the  blank  sheet,  fill  in  NODE  (AO).  NUMBER 
(c.number),  PROJECT  (”DM  Example"),  TITLE  (name),  DATE.  AUTHOR,  and  REV  (version) 
for  the  sheet  on  w'hich  the  AO  node  is  decomposed.  The  resulting  partial  drawing  is  shown  in 
Figure  25. 

These  next  queries  extract  all  activity  boxes  on  the  AO  sheet.  A  join  between  activity  and 
itself  via  act2act  is  needed  to  retrieve  the  desired  tuples.  Note  the  c.numbers  are  extracted  in  a 
separate  query  since  non-decomposed  nodes  yield  no  tuples. 


127 


Figure  25.  AO  Diagram  (partial  drawing  1) 


3«l«ct  a. nan*,  a.z,  ay.  a.noda 
from  activity  a,  act2act  a2a 
vhara  a .nod*. id  *  a2a.child.noda  and 
a2a.parant.noda  in  ( 
selact  a.noda. id 
from  activity  a 
vhara  a.noda  ■  "10"  and 
a  projact.id  in  ( 
salact  p. projact.id 
from  projact  p 

vhara  p.nama  ■  "OH  Exampla"}); 

Inama  |x  |y  Inoda 


Imanaga  alpha  data  I  161  16112 

Imanaga  numaric  data  I  17|  17111 
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select  a.x,  ay,  s.c.number 
from  activity  a,  act2act  a2a,  sheet  s 
where  a. node. id  ■  a2a.child.node  and 
a  node. id  »  s.node.id  and 
a  visible.DRE  »  -1  and 
a2a  parent.node  in  ( 
select  a. node. id 
from  activity  a 
where  a. node  *  "AO"  and 
a  project. id  in  ( 
select  p.project.id 
from  project  p 

where  p.name  •  "DM  Example")), 

lx  ly  Ic.number  I 

I . I 

I . . 1 


Now  the  drawing  tool  can  draw  all  the  boxes  at  the  given  (x,y)  locations,  enter  the  names 
and  node  numbers  into  the  boxes,  and  enter  the  c. number  to  the  lower  light  of  each  activity  box 
that  has  been  decomposed  (none  in  this  particular  case).  The  partial  drawing  resulting  from  this 
is  shown  in  Figure  26. 

The  next  query  extracts  all  the  line  segments  on  this  sheet.  These  line  segments  correspond 
to  the  data  elements.  As  always,  the  (x,y)  pairs  are  only  symbolic  in  this  simple  example  database. 
A  “real”  database  would  have  a  screen  location  represented  in  (x,y). 


select  se.xs,  se.ys,  m  u,  se.ye 
from  segment  se 
where  se. sheet. id  in  ( 
select  s. sheet. id 

from  activity  a,  sheet  s,  act2act  a2a 
where  a. sheet. id  *  s. sheet. id  and 
a  node. id  >  a2a.child.node  and 
a2a. parent .node  in  ( 
select  a. node. id 
from  activity  a 
where  a. node  «  "10"  and 
a  project. id  in  ( 
select  p.project.id 
from  project  p 

where  p.name  >  "DM  Example"))); 
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Figure  27.  AO  Diagram  (partial  drawing  3) 


Now  the  drawing  tool  can  draw  all  the  line  segments  at  the  given  (x.y)  locations  The  partial 
drawing  resulting  from  this  is  shown  in  Figure  27. 

These  next  queries  retrieve  the  tuples  representing  all  the  symbols  at  the  ends  of  the  line 
segments.  The  queries  include  retrieval  of  dots,  arrows,  turns,  tunnels,  to.from.alls,  and  bound¬ 
aries  (ICON!  codes).  As  mentioned  earlier,  each  symbol  has  an  (x.v)  location,  and  some  type  of 
discriminator  or  label. 
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select  sy.x,  «y.f,  do  dot. type 
from  symbol  sy,  dot  do 
shore  do. symbol. id  »  sy. symbol. id  and 
sy  sheet. id  in  ( 
select  s. sheet. id 

from  activity  a,  sheet  s,  act2act  a2a 
where  a.sheet.id  «  s. sheet. id  and 
a  node. id  ■  a2a  child. node  and 
a2a. parent .node  in  ( 
select  a.node.id 
from  activity  a 
share  a. node  »  "10“  and 
a. project. id  in  ( 
select  p. project. id 
from  project  p 

share  p.name  •  "OH  Example"))); 

I*  ly  I  dot .ty I 

I . - . —I 


select  sy.x,  sy.y,  ar . arrow. type 
from  symbol  sy,  arrow  ar 
where  ar.symbol.id  »  sy. symbol. id  and 
sy. sheet. id  in  ( 
select  a.sheet.id 

from  activity  a,  sheet  s,  act2act  a2a 
where  a.sheet.id  ■  a.sheet.id  and 
a.node.id  *  a2a.child.node  and 
a2a. parent .node  in  ( 
select  a.node.id 
from  activity  a 
where  a. node  ■  "40"  and 
a. project. id  in  ( 
select  p. project. id 
from  project  p 

where  p.name  -  "DH  Example"))); 


ly 

1 

arrow.  I 

211 

211 

31 

241 

241 

31 

291 

291 

11 

331 

331 

11 

351 

351 

31 

401 

40 1 

11 

781 

781 

31 

80| 

801 

31 

761 

761 

31 

I 


x 


select  sy.x,  jj.j,  tu. turn. type 
from  symbol  sy,  turn  tu 
where  tu.symbol.id  *  sy.symbol.id  and 
sy  sheet. id  in  ( 
select  (.sheet. id 

from  activity  a,  sheet  s,  act2act  a2a 
where  a. sheet. id  ■  s.sheet. id  and 
a  node. id  »  a2a.child.node  and 
a2a  parent .node  in  ( 
select  a. node. id 
from  activity  a 
where  a. node  ■  "AO"  and 
a. project. id  in  ( 
select  p. project. id 
from  project  p 

where  p.name  »  "DH  Example"))); 


ly 

1  turn 

-t| 

191 

19| 

_ | 

21 

231 

231 

61 

271 

27| 

21 

321 

321 

21 

361 

36 1 

41 

391 

39 1 

2 1 

401 

40| 

61 

431 

431 

01 
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select  sy.x,  ay.y,  tu . tunnel. type 
from  symbol  ay,  tunnel  tu 
where  tu.symbol.id  «  sy.symbol.id  and 
sy. sheet. id  in  ( 
select  a. sheet. id 

from  activity  a,  sheet  s,  act2act  a2a 
where  a. sheet. id  ■  a. sheet. id  and 
a. node. id  ■  a2a.child.node  and 
a2a. parent .node  in  ( 
select  a. node. id 
from  activity  a 
where  a. node  *  "AO"  and 
a. project. id  in  ( 
select  p. project. id 
from  project  p 

where  p.name  »  "OH  Example"))); 


lx  ly  I  tunnel | 


7SI  75 |  -i| 

. I 
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salact  sy.x,  sy.y,  tf * . tf a.labal 
from  symbol  sy,  to.from.all  tf* 
whar*  tf a . symbol. id  •  sy. symbol. Id  and 
sy.shaat.id  in  ( 
salact  s.shaat.id 

from  activity  a,  shaat  s,  act2act  a2a 
whera  a. shaat. id  *  s.shaat.id  and 
a  nod*. id  «  a2a.child.nod*  and 
a2a.parant.noda  in  ( 
salact  a. nod*. id 
from  activity  a 
ahar*  a. nod*  «  "10“  and 
a.projact.id  in  ( 
salact  p.projact.id 
from  projact  p 

ahar*  p.nam*  •  "DH  Example") ) ) ; 


x  I y  I  label 


761  7611 
771  77 | 1 
791  79|1 


salact  sy.x,  sy.y,  bo.icom.coda 
from  symbol  sy,  boundary  bo 
ahar*  bo.symbol.id  »  sy. symbol. id  and 
sy.shaat.id  in  ( 
salact  s.shaat.id 

from  activity  a,  shaat  s,  act2act  a2a 
ahar*  s.shaat.id  *  s.shaat.id  and 
a. nod*. id  ■  a2a.child.ood*  and 
a2a.parant.noda  in  ( 
salact  a. nod*. id 
from  activity  a 
ahera  a. nod*  •  "10"  and 
a.projact.id  in  < 
select  p.projact.id 
from  projact  p 

ahar*  p.nam*  ■  "DH  Example"))); 


1  x 

It 

1 icom. 

c  i 

181 

181X1 

261 

261  Cl 

351 

35101 

Now  the  drawing  tool  can  draw  all  the  symbols  for  each  of  the  line  segments  at  the  given 
(x.y)  locations.  The  partial  drawing  resuiting  from  this  is  shown  in  Figure  28. 

This  next  query  extracts  all  the  labels  for  each  of  the  arrows  on  the  diagram  Associated  with 
each  label  is  the  (x,y)  location  where  the  label  is  to  be  drawn. 
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AUTHOR:  Gerald  R  Morris 

DATE  14Feb89 

READER 

PROJECT  DM  Example 

REV  1  0 

DATE 

NODE 

TITLE  manage  database 

NUMBER  2 

AO 

Figure  28.  AO  Diagram  (partial  drawing  4) 


select  1.x,  l.y,  Inane 
from  label  1 
where  1  sheet. id  in  ( 
select  s. sheet. id 

fron  activity  a,  sheet  a,  act2act  a2a 
where  a. sheet .id  *  s. sheet. id  and 
a2a.child.node  >  a. node. id  and 
a2a. parent .node  in  ( 
select  a.node.id 
fron  activity  a 
where  a. node  «  "iO"  and 
a  project. id  in  ( 
select  p. project. id 
fron  project  p 

where  p.nane  ■  "ON  Exanple"))); 
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X 


I  j  I  name 


171 

17|us«rdata  1 

201 

20 1 unnabar  1 

221 

22lualpha  1 

2S  | 

25 1 rulas  1 

281 

28 1  number iula i 

301 

30 1 alphar^les I 

341 

341  feedback  1 

371 

37 1 numbennsgs 1 

411 

41 1 alphamsg*  1 

SSI 

S5 1 fctrl/413  1 

851 

85 1 error  code  1 

Now  the  drawing  tool  can  enter  all  the  labels  for  each  of  the  data  elements  at  the  given  (x.y) 
locations.  The  drawing  resulting  from  this  is  actually  the  same  as  the  complete  drawing  shown  in 
Figure  8. 

These  next  queries  extract  the  additional  graphics  entities  on  the  drawing.  In  this  particular 
instance,  there  are  no  additional  graphics  entities,  i.e,  squiggles,  and  footnotes. 


select  s.il,  s.yl,  a.x2,  s.j2,  3 . x3 ,  s.j3,  s.x4,  s .  y4 
from  squiggle  a,  graphic*  g 
where  s  graf.id  ■  g  graf.id  and 
g  shear. id  in  ( 
selact  a . sheet.id 

from  activity  a,  shaat  s,  act2act  a2a 
where  a. nods. id  -  a2a.child.noda  and 
a. sheet. id  ■  8. shaat. id  and 
a2a.parant.noda  in  ( 
salact  a. nods. id 
from  activity  a 
vhara  a. nods  ■  "40"  and 
a.projact.id  in  ( 
salact  p.projact.id 
from  projsct  p 

share  p.nama  a  "DM  Exampla"))); 

I x 1  lyl  1x2  I y2  1x3  I y3  1x4  Iy4  I 

I . I 

I .  -I 


136 


salact  xnark*n . z  ,  ymark »n.y,  n.labal,  xtext*f.x, 
nt.lina.no,  nt.taxt.line 

from  not#  n,  nota.text  nt ,  footnota  f,  graphics  g 
whara  n.graf.id  •  g.graf.id  and 
f  graf.id  >  g.graf.id  and 
nt. graf.id  ■  g.graf.id  and 
g  shaat.id  in  ( 

select  s. shaat.id 

from  activity  a,  sheat  s,  act2act  a2a 
whara  a.noda.id  *  a2a.child.noda  and 
a. shaat.id  •  s  shaat.id  and 
a2a. parent .noda  in  ( 
salact  a.noda.id 
from  activity  a 
whara  a.noda  «  "10"  and 
a. projact. id  in  ( 
salact  p.project.id 
from  projact  p 

whara  p.nama  •  "DM  Exampla"))); 

I xmark  I ymark  llabel  Ixtaxt  lytaxt  I lina.n I t axt.lina 


Extract  Essential  Data 

The  following  queries  extract  essential  data  from  the  Ingres  DBMS  implementation  of  the 
IDEFo  database.  The  first  set  of  queries  extract  the  data  for  a  typical  activity  data  dictionary 
The  second  set  of  queries  extract  the  data  for  a  typical  data  element  data  dictionary.  As  with  the 
drawing  data  above,  these  queries  are  associated  with  the  diagram  shown  in  Figure  5>. 


Activity  Data  Dictionary.  These  next  queries  illustrate  the  extraction  of  the  data  dictionary 
data  (essential  data)  associated  with  a  typical  activity  (A1  in  the  example). 


S ELECT  a . nut , a . nod* , a . vars Ion , a . dat a, an. author 
FROM  activity  a, analyst  an, projact  p 
WHERE  an. author. Id  »  a. author. id  and 
a  projact. id  ■  p. projact. id  and 
a  noda  «  "11"  and 
p.nama  ■  "ON  Exampla"; 

Inama  Inoda  Ivarsion  Idata  lauthor  I 


managa  numaric  data 


111 


110 


l02/14/89IGarald  R  Morris 


SELECT  c. changes  /•  Get  the  changes  */ 
FROM  activity  a, act .changes  c, project  p 
WHERE  c. node. id  ■  a. node. id  and 
a  project. id  »  p.project.id  and 
a  node  »  "11"  and 
p.nane  »  "DM  Example"; 

I  changes 

I— . — . 


SELECT  ad. line.no, ad. desc. line  /«  Get  the  description  »/ 
FROM  activity  a, project  p.act.descr  ad 
WHERE  a. node. id  »  ad. node. id  and 
a  project. id  »  p.project.id  and 
a  node  «  "11"  and 
p  name  »  "DM  Example"; 

I line.nldesc.line 


1 1  This  activity  sill 
2 1  handle  numbers 


SELECT  parent's. name  /*  Get  the  parent  activity  */ 
FROM  activity  a, project  p,act2act  a2a 
WHERE  a. node. id  »  a2a. parent .node  and 
a2a.child.node  in  ( 

SELECT  a. node. id 

FROM  activity  a, project  p 

WHERE  a. project. id  »  p.project.id  and 

a. node  »  "11"  and 

p . name  »  "DM  Example"); 

I  parent  | 

I . I 

I  manage  database  I 


SELECT  d  name , a2d . icom.type  /»  Get  the  data  elements  •/ 
FROM  activity  a,data.elem  d,act2data  a2d, project  p 
WHERE  a. node. id  *  a2d.node.id  and 
d  data. id  •  a2d.dat a.id  and 
a  project. id  «  p.project.id  and 
a  node  »  "11"  and 
p  name  >  "DM  Example"; 

I  name  licom.tl 


I  unumber  1 1 
Inuraberrules  1C 
Inumbenssgs  |0 
I  errors  II 
I . 
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SELECT  rt .ref. type  ,r  ref.line ,r . line.no  /«  Get  the  references  «/ 
FROM  activity  a, project  p, ref. type  rt .reference  r,act2ref  a2r 
WHERE  a. node. id  ■  a2r.node.id  and 
r  ref.id  »  a2r.ref_id  and 
r. ref. id  »  rtref.id  and 
a. project. id  «  p. project. id  and 
a  node  •  "41"  and 
p  name  •  "DM  Example"; 


I  ref. type  I  ref. line  llme.nl 

I . - . - . . . - . - . - . I 

Icontract  I  KIR  100028-89-0123  3 . 3 . 2 . 1 . 2a  I  l| 

I _  .  _  i 


Data  Element  Data  Dictionary.  These  next  queries  illustrate  the  extraction  of  the  <lnt 
tionary  data  (essential  data)  associated  with  a  typical  data  element  (unmnber  in  the  exampl 


SELECT  d . name , an . author ,d . version, d . date 
FROM  data.elem  d, analyst  an, project  p 
WHERE  d . namea*"unumber"  and 
d. author. id«an. author. id  and 
d. project. id»p. project. id  and 
p.name«"DM  Example"; 


1  naa« 

1  author 

Iversion 

Idat*  1 

1  unuab«r 

IGerald  R.  Morris 

11.0 

102/14/891 

SELECT  dd. line.no, dd.desc. line  /•  description  •/ 
FROM  data.descr  dd, data.elem  d. project  p 
WHERE  d.name  "•"unumber”  and 
dd. data. id  ■  d.data.id  and 
p  project. id"d. project. id; 

I line.nldesc.line 


II This  is  the  user  numeric  data  I 


SELECT  c. changes  /*  changes  •/ 

FROM  data. changes  c, data.elem  d, project  p 
WHERE  c  data. id«d. data. id  and 
d  name* "unumber"  and 
p  project. id  •  d . pro ject.id ; 

I  changes  I 

I 


SELECT  a. name, a. vhere. used, a. comment  /•  aliases  •/ 

FROM  alias  a, data.elem  d, project  p 
WHERE  a  data.id«d  data. id  and 
d  name •"unumber"  and 
p  project. id  »  d. project. id; 

I  name  Ishere.used  I  comment  I 
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SELECT  parent*d.naae  /•  parents  */ 
FROM  data.elea  d,data2data  d2d 
WHERE  d . data. id*d2d . parent .data  and 
d2d.child.data  in  ( 

SELECT  d. data. id 
FROM  data.elea  d, project  p 
WHERE  d . naae>"unumber"  and 
d . pro ject_id=p . project. id  and 
p.name  =  "DM  Example"); 


SELECT  children»d. name  /•  children  »/ 
FROM  data.elea  d,data2data  d2d, project  p 
WHERE  d . data_id«d2d . child.data  and 
d2d.parent.data  in( 

SELECT  d. data. id 
FROM  data.elea  d, project  p 
WHERE  d . name»"unumber"  and 
dproject_id«p. project. id  and 
p  name  «  "DM  Example"); 


SELECT  dt.type  /•  data  type  •/ 

FROM  data. type  dt, data.elea  d, project  p 
WHERE  dt .data.id>d.data.id  and 
d  name*"unuaber "  and 
p  pro ject.id»d  project. id; 


SELECT  dr  data. range  /•  data  range  •/ 
FROM  data.range  dr, data.elea  d, project  p 
WHERE  dr  data_id«d  data.id  and 
d  name* "unumber"  and 
p . pro ject.id«d . pro ject.id; 


I data.range 


I  integer ’range 


SELECT  m.ainiaua.m.naxiauB  /*  get  ain/aax  •  / 
FROM  ain.aaz  a, data.elea  d, project  p 
WHERE  a  data. id*d . data. id  and 
d . name«"unuaber"  and 
p  project. id»d. project. id; 

I  minimum  I  maximum  | 


SELECT  v. value  /•  data  raluaa  */ 

FROM  data. value  v,data2value  d2v .data.elem  d.project  p 
WHERE  v  value_id*d2v  value. id  and 
d2v  data. id*d. data. id  and 
d  . name* "unumber"  and 
p. pro ject_id«d. project. id; 

I  value  I 


SELECT  a.naae,a2d. icon.type  /*  sources  and  destinations  •  / 

FROM  activity  a, data.elem  d,act2data  a2d, project  p 
WHERE  d . data„id»a2d. data.id  and 
a  node. id«a2d. node. id  and 
d  nane«"ununber"  and 
p  pro ject_id»d. project. id; 

Inane  lieon.tl 

I . I 

I  manage  nuneric  data  II  I 

I . I 

SELECT  rt .ref. type ,r .line.no , r. ref. line  /•  get  references  •/ 

FROM  data.elen  d, ref. type  rt, reference  r, project  p,data2ref  d2r 
WHERE  rt . ref _id«r . ref.id  and 
r  ref. id»d2r .ref.id  and 
d2r .data_id»d. data.id  and 
d  name«"un umber"  and 
p  pro ject_id«d . project. id; 

I  ref .type  I line.n I  ref .line  I 

I . I 

I AFH  I  1I1FH  3S-10,  page  3,  para.  2.3  I 


HI 


Appendix  H.  Example  IDEFq  Nested-Relationa1  Database  Instance 


The  example  nested-relational  database  shown  below  corresponds  to  the  diagrams  shown  in 
Figure  7,  and  Figure  8.  The  example  was  constructed  manually  using  the  relational  implementation 
as  a  starting  point.  Note  that  some  of  the  data  in  the  example  database  is  in  symbolic  form.  e  g., 
the  locations  of  the  various  components,  the  arrow-types,  etc. 


The  nested- relational  database  instance  below  includes  the  names  of  the  relational-valued 
attributes  in  parenthesis  to  make  things  easier  to  understand.  In  addition,  the  table  is  split  into 
three  sections,  activities,  data  elements,  and  sheets. 

project 


Ipro ject.name  I 

I- . I 

I DH  Example  I 

I . I 

(activities) 

I  nod*. id  I  nod*  I  name  I  author  I  version  I  data  I  changes  lc_number  I  parent 

1 . 1 - 1 . 1 . 1 . 1 . I . . I . I . 

t  1 10  Imanaga  databasa  lOerald  R .  Norris  1 1.0  102/14/89  I  ll  I 

, . I . I . I . I . I . I . I . I . 

(act.descr) 

llina.no  Idascr.lina  I 

I  . I . I 

II  I  This  is  tha  contaxt  diagram  I 

12  I  for  tha  data  manager  analysis  I 


(rafrancas) 

I  ref. type  I 


I  military  standard  I 


(ref.lines) 


llina.no 

1  ref. line  1 

11 

|HIL-Std-00091  1 

12 

Ipaga  3  para.  7-S  1 

Istd  operating  procedure  I 


ll 

iSjstsa  Davalopaant  Guids 

12 

1  Draft  4 

(hist. calls) 

Ihist.proj 

1 - - 

Ihist.noda  1 
—  1 . 1 

142 


(data.elens) 

Idata.nane  licom.type 


luserdata  II 
I  rules  1C 
I  feedback  10 


(children) 

I  node. name 

I . 

I manage  numeric  data 
I  manage  alpha  data 


1 . 

1  node. id  1  nod* 

1  nan* 

-i 

1  author 

j version  Idate  Ichanges 

Ic.nujober  Iparent 

12  Ml 

1  manage 

numeric  data  IGerald  R.  Morris 

U.O  112/14/89  | 

12  (manage  < 

(act.descr) 

lline.no  Idescr.line 

I  . I . — 

II  iThis  activity  sill 

I  2  I  handle  numbers 


I . I . . 1 

(refrences) 

I  ref. type  I 

I . I 

I  contract  I 

I . I 

(ref. lines) 

lline.no  I  ref. line  I 

I  . I . 1 

II  I  KIR  100028-89-0123  3.3.2.1.2a  I 

I . I . I 


(hist. calls) 

Ihist.proj  Ihist.node  I 

I . I . I 

I . I . I 

(data.elems) 

Idata.naae  I  icon. type 


I  unumber  1 1 

I  errors  II 

I  number rules  1C 

Inumbermsgs  10 

I . I  — 

(children) 

Inode.naae  I 


I . I 

Inode. id  Inode  Inane  lauthor  Iversion  Idate  Ichanges  Ic. number  Iparent 

I . I - 1 . 1 . 1 . I . I . . I . I . 

13  M2  Imanage  alpha  data  IGerald  k.  Morris  11.0  112/14/89  I  12  Manage 

I . I . I . I . I . I . I . I . I . 

(act.deacr) 


lline.no 

Idescr.line 

11 

(This  activity  will 

12 

1 . 

(handle  alphanuaerics 
-1 . 

1-43 


(refrences) 

1  ref. type 

1  _ _ _ 

1 

1  contract 

1 _ 

1 

(ref.linas) 

1 lina.no 
| - 

1  raf.lina 

i _ 

11 

1 - 

KIR  100028-89-0123  3.3.2.1.2a 

1 _ 

(hist. calls) 

Ihist.proj 
i _ _ 

1  hist. node  1 

1  Flight  Control  |A13  I 

_  r  i 

■  i - - 1 

1 data.naaa 

j _ 

1  icon. type 

1 

1 ualpha 

II 

1 

1  errors 

II 

1 

1 alpharules 

1C 

1 

1  alphansgs 

10 

1 

1  alpha call 

1 . 

IN 

. 1- . 

1 

(children) 


Inode.nane  I 

I . I 

I . I 


m 


(data.elementa) 
Idata.id  I  name 


I  author 


Iversion  Idate 


luserdata  iGeraldR.  Morris  1 1  0 


■I- 


-I- 


(dat a.descr) 


-I . 

102/14/89  | 

-I - I- 


I  changes  'parent 


1 line.no 

t  descr.line 

ii 

iThis  is  the  user 

12 

1 . 

1  input  data 

-1 . . . . 

(refrences) 
I raf .type 


I- 


Imilitary  standard 

I— . 

(raf .lines) 

llina.no  Iref.line 


11  IMIL-Std-00091 

1 2  | page  9  para  8-1 


(aliases) 

- 1 - 

1  name  I 

i _ 

where. used 

1  comment  I 

(min. max) 

1  data. type 

i _ 

1 Minimum 

1  max  imum  1 

i _ i  _  _  »  i 

(range) 

1  data. type 

i _ 

1  range 

1 

i _ _  t 

(values) 

| data. type 

i _ _ 

I  value 

1 

(activiteea) 

1 node .name 

t - 

1 icom.type  | 

Iraanaga  database 


(children) 

I data.naae 


I  unuaber 
I  ualpha 


Idata.id  Inaae 

I - 1 . 


-I 

I  author 


Iversion  Idate 


I  changes  I  parent 


12  I  rules  I  Gerald  R.  Morris  11  0 

I . I . I . I— ■ 

(data.descr) 

lline.no  Idescr.line 


-I- 


102/14/89  I 


I  . I . 

II  I  This  is  the 

12  I  database  rules 

I . I . 


I 

I 

I 


115 


(refrences) 
I ref .type 


[military  standard 

I— . 

(raf .lines) 


1 line.no 

1  ref .line 

i 

ii 

|NIL-Std-00091 

i 

12 

Ipage  9  para.  8-2 

i 

(aliasas) 

1  name  | 

where.used  [comment 

i 

(min.max) 

1  data. type 

I  minimum  1  maximum  1 

(ranga) 

1  data. type 

1  range  1 

(values) 

1  data. type 

I  value  I 

(activitaas) 

1 node. name 

1 - 

1 icom.type  t 

i  manage  databaaa 


(childran) 

Idata.naae 


I  numberrules 
I  alpharulaa 


Idata.id  Inane 


I  version  I  data  I  changes  I  parent  I 


Ifaadback  IGaraldR.  Norris  ll.O 


(data.dascr) 


102/14/89 


lline.no 

1 deacr.line 

i 

ii 

1  This  is  tha 

1 

12 

1 . 

lusar  feedback 
-1 . 

1 

. t 

(refrences) 
I ref .type 


Inilitary  standard 


(ref .lines) 


llina.no 

1  raf .line 

11 

IHIL-Std-00091 

12 

Ipaga  9  para.  8-3 

(aliasas) 

1  name  1 

1  share. used  1  consent 

1 

I - - - 

(mm. max) 

Idata.type  I  minimum  I  max  imum  I 


(rang*) 

Idata.type  I  rang*  I 


(values) 

Idata.type  lvalue  I 


1 - - 1 - 

(act ivitees) 

- 1 

Inode.name 

1 icom.type 

1  manage  database 

10 

(children) 

1 data.name 

i 

1  numbennsga 

i 

1 alphamsgs 

i . 

i 

Idata.id  Inane  lauthor  Iversion  Idate  Ichanges  Iparent  I 

I . -I . I . i . I . I . -I . I 

14  lununber  I  Gerald  R.  Norris  1 1 . 0  102/14/89  I  luserdata  I 


(data.deser) 

lline.no  Idescr.lina 

I  . I . 

II  I  This  is  the  user  numeric  data 

I . I . 

(refrences) 

I  ref .type  I 


(ref. lines) 

lline.no  I  ref .line 


I 

I 

I 

I 


Il  I 1FH  35-10  page  3  para.  2.3 


I . I . 

(aliases) 

I  name  I ehere.used  I  comment  I 

I . I . I - 1 

I . I . I . I 

(min. max) 

Idata.type  I  min  imum  I  max imum  I 

I . I . I . I 

I . I . I . I 

(range) 


Idata.type  I  range  I 


,  -- — - 

I  integer 

i _ _ 

1  integer ’range 

i _ 

(values) 

Idata.type 

1 

1  value 

1  1 

(activitees) 

Inode.nane  I  icon. type  I 


I  manage  numeric  data  II  I 

I . I . I 


! 


U7 


(children) 

I  data. name  I 

I . I 

I— . I 

Idata.id  Iname  I  author  Iversion  Idata  Ichanges  Iparent 

I . I . I . I . I . I . ~l . — 

IS  lualpha  iGeraldR.  Morris  1 1  0  102/14/89  I  lusardata 

I . I-— . I . I . I-— . I . I - 

(data.descr) 

llins.no  Idsscr.lins  I 

I  . I . I 

II  IThs  users  alphanumeric  data  I 

I . I . 1 


(refrences) 

I  ref. type  I 


I 

I 

I 


UFH  I 


I . I 

(ref. lines) 


1 lint.no 

1 ref .line 

ii 

UFH  35-10 

page  3  para .  2.4 

(aliases) 
Iname  1 

1  ehere.used 

I  comment  1 

(min. max) 

1  data. type 

1 minimum 

1 maximum  1 

(range) 

Idata. type 

1  range 

1 

lascii 

lascii1 rang*  | 

(values) 
Idata. type 

lvalue 

1 

(activitees) 
Inode. name 

1  icon. typo  1 

1  manage  alpha  data 

II 

i 

(children) 

Idata. name 

1 . 

1— . 

Idata.id  Iname  I 

1 

•1 

■1 

author 

1  version  Idate  1 

16  1  number rules  1 

iGerald  R. 

Morris  ll  0  102/14/89  1 

(data.descr) 

lline.no  Idescr.line 

1 

I  parent 


I  rules 

I . 


ll  I  Rules  for  numeric  data  I 
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(refrences) 

I  ref. type  I 

I . 1 

I AFH  I 

I . I 


(ref .lines) 

lline.no  I  ref. line 


ll  I  4FM  3S-10  page  4  para.  3.2 


(aliases) 

Inane  I  share. used  I  comment  I 

I . I . I . I 

| - _.| . | . . 1 

(min.max) 

Idata.type  Ininimun  Inaxinon  I 

I . I . I . I 

I . I . I . I 

(range) 

Idata.type  I  range  I 

I . I . I 


I 

I 

I 

I 


(values) 

Idata.type  lvalue 

I . I . 


(activitees) 

I node.nane  I  icon. type  I 

I . I . I 

I  manage  numeric  data  |C  I 

I . I . I 

(children) 

Idata.naaa  I 

I . I 

I . I 

I  data. id  I  name  I  author  I  vers  ion  I  date  I  changes 

I . I . I . I . I . I . 

17  lalpharules  IGerald  R.  Norris  1 1.0  102/14/89  I 

I . I . I . —  I . I . I . 


(data.descr) 

lline.no  Idescr.line 

I  . I . 

II  I  Rules  for  alphanumeric  data 


(refrences) 
I  ref .type 


MFH 

I . 

(ref. lines) 

lline.no  I  ref. line 

I . I . 


I 

I 

I 

I 


I 

I 

I 

I 


I 

I 


11 

| - 

(aliases) 

I  name 


liFH  35-10  page  4  para.  3.3  I 

-I . - . I 

I  share. used  Icoaaent  I 


I  parent 


I  rules 

I . 


I 

I 

I 

I 


(min.max) 

Idata.type  (minimum 


I 


I 


I  maximum  I 
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(range) 

Idata.typa  I ranga 


(valttas) 

Idata.typa  lvalue  I 


(activitaas) 

Inode.naae  I  icon. type  I 


Imanaga  alpha  data  |C  I 


(children) 

Idata.name  I 


I . I 

Idata. id  I  name  I  author  Iversion  Idata  Ichanges  Iparent  I 

I . I . I . I - 1- . I . I . I 

18  Inumbermago  IGarald  R.  Morris  1 1  - 0  (02/14/89  I  Ifeedback  I 

I . I- . . 1 . . I . I . I . I . I 

(data.dascr) 

llina.no  Idascr.lina  I 

I  . I . —  I 

II  IFaadbackfor  numeric  data  I 

I . I . I 

(refrancas) 

Iref.typa  I 

I . I 

IAFH  | 


(raf.linaa) 

llina.no  Iraf.lina  I 

I  . I . I 

II  | AFM  35-10  paga  5  para.  4.5  I 

I . I . I 

(aliases) 

I  name  lahara.usad  Icoaaant  I 

I . I . I . I 

I . I . I . I 

(min.max) 

Idata.typa  Iminimum  Imaximum  I 

I . I . I . I 

I . I . I . I 

(ranga) 

Idata.typa  I ranga  I 

I . I . I 

I . I . I 

(valuas) 

Idata.typa  lvalue  I 


(activitaas) 

I  node. name  I icon. type  I 

I . I . I 

Imanaga  numeric  data  10  I 


(childran) 

Idata.naaa  I 


Idata. id  jname 


I alphaasgt 

i _ 


I  author  I  Torsion  Idata  I  changes  I  parent  I 

I . I . I . I . I . I 

IQerald  R.  Morris  11.0  102/14/89  I  Ifeedback  I 
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(data.descr) 

lline.no  Idescr.line  I 


|1  IFeedback  for  alphanuaeric  data  I 


(ref ranees) 
I  ref .type 


MFH 


(ref. lines) 

lline.no  I  ref. line  I 

I- . I . 1 

11  I AFH  35-10  page  5  para.  4.6  I 

I . I . 1 


(aliases) 

I  name  Ishere.used  I  comment  I 


(min. mar) 

Idata.type  Iminimua  Imariaum  I 

I . I . I . I 

I . I . I . —  I 

(range) 

Idata.type  I  range  I 


(values) 

Idata.type  lvalue  I 


(activitees) 

Inode.naae  I icoa.type  I 

I . I . I 

I  manage  alpha  data  10  I 


(children) 

Idata.naae  I 

I . I 

Idata.id  Inaae  lauthor  Iversion  Idate  Ichanges 

I . I— . —  I . I . I . . I . 

110  I alphacall  I  Gerald  R.  Morris  1 1 . 0  102/15/89  I 

I . I . I . I . I . I . 

(data.descr) 

lline.no  Idescr.line  I 

I  . I . I 

II  ISee  Flight  Control  fode  113  I 

I . I . I 

(refrencea) 

I  ref. type  I 


I  parent 


I 


(ref .lines) 

lline.no  Iref.line 

I . I . 


(aliases) 

Inaae  Ishere.used  Icoaaent  I 


(min. aar) 

Idata.type  Iminiaua  laaxiaua  I 


I 

I 

I 
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(range) 

Idata.type  Irange  I 


( values) 

I  data. type  lvalue  I 

I - |- . —  I 


(activitees) 

I  node .name  I icon. type  I 

I - - - I . . I 

Imanage  alpha  data  IK  I 


(children) 

I  data. name  I 


I . I 

Idata.id  Inane  lauthor  Iversion  Idate  Ichanges  Iparent  I 

I - 1' . I - - - I . I - 1 - 1 . I 

111  lerrors  IGeraldR.  Morris  ll.O  102/17/89  I  I  | 

. I . I . - . -I - 1 - 1 . 1 . —  I 

(data.descr) 

lline.no  Idescr.line  | 


(refrences) 

Iraf.type  | 

I . 1 

I . I 

(ref. lines) 

lline.no  I  ref. line  | 


(aliases) 

Inane  lahere.used  I  consent  I 


(min.nax) 

Idata.type  Inininun  Inaxinun  I 


( range) 

Idata.type  Irange  I 

I . —  I . I 

| - 1 . , 

(values) 

Idata.type  lvalue  I 


lerrcode  I  bad  input  I 

lerrcode  Ibad  output  I 

I . I- . I 

(activiteea) 

I  node. nans  licon.type 

I . . I . . 

Inanage  nuneric  data  II 

Imanage  alpha  data  II 


(children) 

Idata.name  I 
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Ivarsion  Idata  I 

| - 1— . | 

11. 0  102/14/891 

I . -I . —  I 


11  I 

| - 1 

(location) 


Ixs  lys 

1  —  1  — 
13  13 

1  — 1  — 
(symbols) 

!*  It 

Ixa  lya  1 

-1 - 1 - 1 

14  14  1 

Itypa. symbol  1  symbol. typa  I 

14 

1  — 

14 

I  arrow 

.  i _ 

1  - -  1 

J right. arrow  J 

12 

1— — 

i 

i 

1  — 
16 
I-- 

i _ 

-1  — 
16 

-1  — 
.  | _ 

■i— 

17 

■1  — 

-1  — 1 
17  | 
■1  — 1 

17 

17 

1  arrow 

1  down. arrow  | 

1— — 
13 

— 

i 

i 

1  — 
19 

1  — 

-I-- 

19 

-1  — 

■  i— 
110 
-1  — 

-I---I 

1 10  | 
-1  —  1 

lio 

110 

1  arrow 

1  right. arrow  | 

( squigglas) 

III 

III 

1x2 

Ij2 

1x3  Iy3  1x4  1  y4 

1 12 

112 

113 

113 

a-  1 - 

114  114  115  115 

- 1 - 1 - i - i  ... 

(raata.notas) 

I labal  |x  |y  I 


(nota.taxt ) 

llina.no  Itaxt.lina 
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(foot. notes) 

1 labal  Ixm 

i  _  i  __ 

1  yffl 

1 xn  1 yn 

I  1 

II  111 

_  1 

Ill 

1 - 1 

i 90  J  90 

(nota.taxt) 


llina.no 

! text.line 

11 

Ian  example  decomposition 

12 

1 . . 

Inot  completed 

-i . 

(feos) 


(label  lx 

ly  Ipictnre 

1 

(labels) 

1  data_id. 

(name 

lx 

ly 

1 

ii 

1 userdat a 

12 

12 

1 

12 

1 rulaa 

IS 

IS 

1 

13 

1— . 

1  feedback 
■i — . 

18 

-1  — 

18 

-1  — 

1 

-1 

1 c. number 

Inode  (name 

( author 

1  version 

1  date 

12 

(AO  (manage  database  iGerald  R.  Morris 

1 1.0 

102/14/89 

(boxes) 

Inoda 

1  name 

lx  ly  Ivisible.DRE 

1 

111 

U2 

1  Manage  numeric  data 

1  manage  alpha  data 

116  116  |  -1 

117  |17  |  -1 

1 

1 

I . I - 1 - 1 . 1 


(segments) 
Idata.id  t 

I  . I 

II  I 


(location) 


Ixa  lys 

Ixa  lya  1 

118  118 

119  119  1 

(symbols) 

1*  ly 

1 typa.symbol 

1  symbol. type 

118  118 

1  boundary 
- 1 - - 

HI 

-  1 - 

I . I 

(4  | 


1— — 

1 19 

—  1 

1 19 

■1 - 1 - 1 

121  121  1 
•1  — 1  —  1 

121 

121 

1  arrow 

I  right-arrow 

15 

| - 

—  1 
1 

i 

119 

1 19 

-i — i — i 
123  123  1 
■1 - 1 - 1 

119 

119 

1  tarn 

I  right-down 

•— i . 
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123  123  124  124  I 


123 

124 

123 

124 

'  |  — - 

I  turn 

1  arrow 

1  down-right 
(right-arrow 

(2 

| - 

i 

i 

1  — 
126 

1  — 

1  — 
126 

1  — 

-i — i — i 

127  127  | 

■1 - 1  —  1 

126 

126 

1  boundary 

IC1 

127 

127 

1  turn 

Iright-down 

1— — 
16 

| - 

i 

1  — 
127 

1  — 

■1  — 
127 
•1—  - 

•i— i — i 

129  129  | 

■1  — 1  — 1 

129 

129 

1  arrow 

1  down-arrow 

1 . 1 

17  I 

I . I 

| - 1 - 1 - 1...| 

127  127  132  132  I 


32  132  I  turn  (right-down  I 

—  I  — I . i . I 

—  I  — I  —  I  — I 
32  132  133  133  I 

—  I  — I  — I - I 


33  133  I  arrow  Idown-arrow  I 


13  I 


I  — I  — I  — I  — I 

135  135  136  136  I 


I  — I  — I . I - 1 

I3S  135  | boundary  1 01  I 

135  135  I  arrow  I  right-arrow  I 

I  — I  — I . - . I . —  I 


18 


38  138  139  139  I 
- 1 - I - I - I 


139 

|39 

1  turn 

— - 1 . 

1  right-down 

139 

139 

140  140  1 
-1 - 1 - 1 

140 

140 

1  turn 

Idown-right 

140 

140 

•1 - 1 - 1 

136  136  1 
■1 - 1 - 1 

1  _  *  1 _ 1 _  _ 1 

1 9 

| - 

142 

142 

1  —  1 - 1 

143  143  1 

1  —  1 - 1 

143 

143 

1  turn 

i 

1  right-up 

143 

143 

136  136  | 

136 

136 

1  turn 

1  up-right 

1— - 
1 10 

1— — 

— 

140 

140 

i— i— i 
141  141  1 

1 - 1 - 1 

140 

140 

1 arrow 

1  down-arrow 

1— - 
IU 
| - 

— 

I-- 

175 

I-- 

175 

i — i— i 
178  |76  1 

I - I - I - ! - 1 


I 

I 


I 

I 


I 

I 


I 

I 

I 


I 

I 

I 


f 

I 

I 


I - 1 - I . I . I 

1 75  1 75  Ituiuial  |hidd«n-sourc»  I 

176  176  Ito-from-all  II  I 

176  176  larros  Iright-arrou  I 

I  — I  — I . I . I 


| 1 1 - 1 - 1 

177  |77  178  178  I 
I  — I  — I  — I  — I 


177  |77  lto-fro«-all  |i 

178  178  larro*  lright-«rro» 


| - 1 - 1 - , - 1 

179  179  180  180  I 
| - 1 - 1 - 1  — | 


I 

I 

I 

I 
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I— I— I . I . I 

179  | 79  I  to-fron-all  |i  | 

180  180  I  arrow  I  right-arrow  | 

I  — I  — I . — -I . I 

( squiggles) 

Ixl  | yl  1x2  |y2  1x3  I y3  1x4  | y4  | 

| - | - 1 - 1 - | - 1.„| - | - , 

| - | - 1 - 1 - |  — | - | - | - | 

(mata.notas) 

llabal  lx  ly  I 


(nota.taxt) 

llina.no  Itaxt.lina 


I . “I . I 

(foot.notaa) 

llabal  Ixm  I  ym  I xn  lyn  I 

| - - 1 - 1 - 1 

| - 1 - 1 - 1 - 1 - , 

(nota.taxt) 

llina.no  Itaxt.lina  I 


I . I . 

(faos) 

llabal  lx  |y  Ipictura  I 

I . I  — I  — I . I 


abala) 
Idata. 
| - 

id  )naa« 

lx 

"  1 

IjT 

11 

lusardata 

117 

117 

14 

1 un unbar 

120 

120 

IS 

lualpha 

122 

122 

12 

1 rulas 

1 25 

125 

16 

1 numbarrulas 

128 

128 

17 

1 alpharulas 

130 

130 

13 

1 f aadback 

134 

134 

18 

1  nunbamsga 

137 

137 

19 

1 alphansga 

141 

1 41 

110 

lfctrl/413 

155 

155 

111 

1 . 

larror  coda 

185 

185 

157 


Appendix  l.  SQL/XF  Script $ 


This  appendix  includes  the  SQL/NF  scripts  that  create  the  nested-relati. mal  <latahase,  p 


h>rm  a  bulk  load,  and  bulk  erase  of  the  database,  show  the  contents  of  the  nested-relational  databa 
and  extract,  data  from  the  database. 


Create  Tables 


The  following  SQL/NF  script  creates  the  schema  for  the  nested-relational  implementation 
the  IDEFq  database. 


SCHEME 

TABLE  DESCRIPT 

ITEM  lina.no  IITEGER  2 
ITEM  dasc.lina  CHARACTER  60 
TABLE  REF 

ITEM  raf.typa  CHARACTER  25 
ITEM  (TABLE  raf. linos 
ITEM  lina.no  IITEGER  2 
ITEM  raf.lina  CHARACTER  60) 

TABLE  IOTETEHT 

ITEM  lina.no  IITEGER  2 
ITEM  taxt.lina  CHARACTER  60 
SCHEMA 

TABLE  PROJECT 

ITEM  pro jact. naaa  CHARACTER  12  UIIQUE 
ITEM  (TABLE  actiaitias 

ITEM  noda. id  IITEGER  4  UIIQUE  IDT  IULL 

ITEM  noda  CHARACTER  20 

ITEM  naaa  CHARACTER  25 

ITEM  author  CHARACTER  20 

ITEM  Torsion  CHARACTER  10 

ITEM  data  CHARACTER  8 

ITEM  changaa  CHARACTER  60 

ITEM  c.nuabar  IITEGER  4  REFEREICES  PROJECT . ahaat* . c.numbar 
ITEM  parant  CHARACTER  25  REFEREICES  PROJECT  act iait ias . naaa 
ITEM  (TABLE  act.daicr  DESCRIPT) 

ITEM  (TABLE  rafrancas  REF)  /•  confusing  naaa  choica  hsra!  •  / 

ITEM  (TABLE  hist. calls 

ITEM  hist. pro j  CHARACTER  12 
ITEM  hist. noda  CHARACTER  20) 

ITEM  (TABLE  data.alaas 

ITEM  data. naaa  CHARACTER  25  REFEREICES  PROJECT  data.eleaants  nama 
ITEM  icoa.typa  CHARACTER  1) 

ITEM  (TABLE  childran 

ITEM  noda. naaa  CHARACTER  25  REFEREICES  PROJECT  act  iaitias . nama) ) 
ITEM  (TABLE  data.alaaants 

ITEM  data. id  IITEGER  4  UIIQUE  IOT  IULL 
ITEM  naaa  CHARACTER  25 
ITEM  author  CHARACTER  20 
ITEM  Torsion  CHARACTER  10 
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ITEM  date  CHiRiCTER  8 
ITEM  changes  CHiRiCTER  60 

ITEM  parent  CHiRiCTER  25  REFEREICES  PROJECT . data.elements . name 
ITEM  (TiBLE  data.descr  DESCRIPT) 

ITEM  (TiBLE  refrences  REF) 

ITEM  (TiBLE  aliases 

ITEM  name  CHiRiCTER  25 
ITEM  share. used  CHiRiCTER  25 
ITEM  comment  CHiRiCTER  25) 

ITEM  (TiBLE  min.max 

ITEM  data.type  CHiRiCTER  25 
ITEM  minimum  CHiRiCTER  IS 
ITEM  maximum  CHiRiCTER  15) 

ITEM  (TiBLE  range 

ITEM  data.type  CHiRiCTER  25 
ITEM  range  CHiRiCTER  60) 

ITEM  (TiBLE  values 

ITEM  data.type  CHiRiCTER  25 
ITEM  value  CHiRiCTER  IS) 

ITEM  (TiBLE  activitees 

ITEM  node. name  CHiRiCTER  25  REFEREICES  PROJECT  activities  name 
ITEM  icom.type  CHiRiCTER  1) 

ITEM  (TiBLE  children 

ITEM  data. name  CHiRiCTER  25  REFEREICES  PROJECT . data.elements . name) 
ITEM  (TiBLE  sheets 

ITEM  c. number  IITEGER  4  UIIQUE  IOT  HULL 
ITEM  node  CHiRiCTER  20  REFEREICES  PRO JECT . act ivities . node 
ITEM  name  CHiRiCTER  25  REFEREICES  PROJECT. activities  name 
ITEM  author  CHiRiCTER  20  REFEREICES  PROJECT . activities . author 
ITEM  version  CHiRiCTER  10  REFEREICES  PROJECT . act ivit ies . version 
ITEM  date  CHiRiCTER  8  REFEREICES  PRO JECT. act ivit ies  date 
ITEM  (TIBLE  boxes 

ITEM  node  CHiRiCTER  20  REFEREICES  PRO JECT . act ivit ies . node 

ITEM  name  CHiRiCTER  25  REFEREICES  PROJECT . activities . name 

ITEM  x  IITEGER  2 

ITEM  y  IITEGER  2 

ITEM  visible.dre  IITEGER  2) 

ITEM  (TiBLE  segments 

ITEM  data. id  IITEGER  4  REFEREICES  PROJECT. data.elements  data.id 
ITEM  (TiBLE  location 
ITEM  xs  IITEGER  2 
ITEM  ys  IITEGER  2 
ITEM  xe  IITEGER  2 
ITEM  ye  IITEGER  2) 

ITEM  (TiBLE  symbols 
ITEM  x  IITEGER  2 
ITEM  y  IITEGER  2 
ITEM  type.symbol  IITEGER  2 
ITEM  symbol. type  IITEGER  2)) 

ITEM  (TiBLE  squiggles 
ITEM  xl  IITEGER  2 
ITEM  yl  IITEGER  2 
ITER  x2  IITEGER  2 
ITEM  y2  IITEGER  2 
ITEM  x3  IITEGER  2 
ITEM  y3  IITEGER  2 
ITEM  x4  IITEGER  2 
ITEM  y4  IITEGER  2) 

ITEM  (TiBLE  meta.notes 
ITEM  label  CHIRICTER  1 
ITEM  x  IITEGER  2 
ITEM  y  IITEGER  2 

ITEM  (TIBLE  note.text  IOTETEXT) ) 

ITEM  (TiBLE  foot.notes 
ITEM  label  CHiRiCTER  1 
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ITEH  zb  IITEGER  2 
ITEM  ym  IITEGER  2 
ITEH  zn  IITEGER  2 
ITEH  yn  IITEGER  2 
ITEH  (TABLE  note.tezt  I0TETEXT) ) 

ITEH  (TABLE  feos 

ITEH  label  CHARACTER  1 
ITEH  z  IITEGER  2 
ITEH  y  IITEGER  2 
ITEH  picture  CHARACTER  60) 

ITEH  (TABLE  labels 

ITEH  data. id  IITEGER  4  REFEREICES  PRO JECT . data. elements . data. id 
ITEH  naaa  CHARACTER  10 
ITEH  z  IITEGER  2 
ITEH  y  IITEGER  2) 


Load  Database 

The  following  SQL/NF  script  does  a  bulk  load  rf  the  data  in  the  example  database  into 
the  nested-relational  implementation  of  the  IDEF0  database.  Note  that  Roth's  SQL/NF  data 
manipulation  language  does  not  actually  contain  the  DML  command  which  allows  a  bulk  load  d  im 
syntax  shown  below  is  based  on  the  syntax  associated  with  the  Ingres  SQL  Note  that  a  percent 
sign  (7c)  is  used  to  delimit  nested  relations  (as  denoted  by  the  =c0%  format),  and  a  comma  or 
carriage  return  are  used  to  delimit  atomic  values  (as  denoted  by  the  =c0  format). 


COPY  TABLE  project 

( 

pro ject_name«cO, 

ac  t  i*  it  i«a  (nod*.  id»cO  ,nod*»cO ,  nameBcO , aot hor»cO , 

ve rsion«cO, dat e»cO ,changes«cO ,c_number»cO .parent »c0 , 
act_descr(line.no«cO,dese.line”cO)*cOX , 

ref  rences (ref .type»cO, ref. lines (line. no«cO, ref _line«cO)»cOX)«cOX, 
hist. calls (hist. pro j«cO, hist. node»cO)»cOX, 
data_elens(data_naae«cO , icom_type«cO) »cOX , 
children (node. name*cO)»cOX 

>*eOX. 

dat a. element s (data. id«cO ,name*cO , anthor>cO , 

»ers ion«cO  ,dat e«cO ,changes«cO ,parent»cO , 
data.descrdine.noscO  ,desc_line»cO)«cOX , 

ref  ranees  (ref  .type»cO,ref.lines(  line.  no»cO ,  ref  _line»cO)»cOX)_cOX, 

aliases  (na»e«cO.  share  _ttsed»cO,coss»ent»eO)»cOX , 

min_maz(data_type»c0.miniBn«-cO  ,maziaua«cO)»cOX, 

range (data. type »c0 ,range»cO)«cOX . 

ralues (data.t ype»cO , »alae»cO) *cOX , 

children (dat s_name»cO)»cOX 

)*cOX. 

sheet s (c.noaberecO , node«cO , naae«cO , author*cO , ears ion*cO ,  dat a*cO , 
boxes (node«cO,nSBe*cO ,z«cO,yecO , risible _dre»cO)»cOX . 
segment s( dat a. id»cO,loc at  ion (xa*cO ,ys-cO ,xe*cO ,ye»cO)*cOX , 
symbols ( z»cO . y»cO . symbol. type«cO , type. symbol»cO) «cOX ) »cOX , 
squiggles(zl»eO,yl»cO,x2»cO,y2»cO, x3»c0, y3«c0,z4»c0 ,y4»cO)»cOX . 
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oota.notoa  (Iab«l*c0,x»c0,]r»c0,note  .text  (line_no«cO,  text  _line*cO)*cOy.)=cO'/. , 
t  oo  t  .no  t  as  (label»cO ,  xa»cO ,  fo»cO ,  xji»cO ,  yn=cO , 
note. text  (Iine_no«c0,text.line«c0)»c0y,)=c0y. , 
feos(label»eO ,x»cO ,y»cO,pieture«cO)»cOX, 
labels  (dat a. id*cO  ,naiMcO ,  x«cO ,  y«cO)»cOX , 

>=cO% 

)  fromnested_example.dat; 

Erase  Database 

The  following  SQL/NF  script  eliminates  all  the  data  in  the  nested-relational  implementation 
of  the  IDEFo  database. 

DELETE  FROH  project; 

Show  Database 

The  following  SQL/NF  script  shows  all  the  data  in  the  nested-relational  implementation  of 
the  IDEFo  database. 

SELECT  *LL  FROM  project; 

Erl  met  Drawing  Data 

The  following  query  extracts  drawing  data  from  the  nested-relational  implementation  of  tin- 
IDEFo  database.  The  query  is  associated  with  the  diagram  shown  in  Figure  8. 


SELECT  (SELECT  ILL  BUT  segments . data.id .labels  data.id  FROM  shaata  WHERE  node  *  "AO") 
FROM  project 

WHERE  project. name  *  "DM  Example"; 

(sheets) 


1 c. number 

Inode  Iname 

1  author 

1  version 

Idata 

12 

1  AO  1  manage  database 

iGerald  R.  Morris 

11. 0 

102/14/89 

(boxes) 

!  node 

1  name  1 x 

ly  1  visible. DRE 

1 

IA1 

112 

I  manage  numeric  data  1 16 
1  manage  alpha  data  1 17 

116  |  -1 

117  I  -1 

1 

1 

| - 1 - 1 - - 1 


( segments) 
(location) 


1  xs 

ly 

Ixa  lye  1 

118 

118 

119  119  1 

(symbols) 

1  X 

ly 

1  type. symbol 

|  symbol. type  1 

1 18 

118 

1  boundary 

III  1 

119 

i— 

119 

1- 

121  121  1 

121 

121 

1  arrow 

Iright-arros  1 

119 

I” 

119 

1” 

123  123  1 

119 

119 

1  turn 

| right-down  1 

123 

1- 

123 

1- 

1 - 1 - 1 

124  124  1 

123 

123 

1  turn 

Idosn-right  1 

124 

124 

I  arrow 

Iright-arros  1 

126 

■  i— 
126 
•1  — 

■  i — i— i 

127  127  | 

126 

126 

1  boundary 

IC1  1 

127 

127 

I  turn 

I  right -down  1 

127 

i— 

127 

1- 

129  129  1 
| - 1 - 1 

129 

129 

I  arrow 

I  down-arrow 

127 

i” 

127 

I-- 

132  132  1 
| - 1 - 1 

132 

132 
-1  — 

(turn 

I  right-down 

-i . 

l(j  2 


32 


33 


35 


38 


39 


39 


40 


40 


42 


43 


43 


36 


40 


40 


75 


77 


32 


33 


35 


38 


39 


39 


40 


40 


42 


43 


43 


36 


40 


40 


75 


77 


33  |33  I 


36  |36  I 
—  I  — I 


boundary 

arrow 


—  I  —  I 
39  139  | 
- 1 - 1 


turn 


- 1  —  1 

40  |40  I 
- 1  —  1 


turn 


- 1  — | 

36  |36  I 
- 1  — | 


—  I - 1 

43  |43  I 
- 1 - 1 


turn 


- 1 - 1 

36  136  I 
—  I - 1 


turn 


- 1  — | 

41  141  I 
—  I  — I 


arrow 


—  |  — | 
76  176  I 
—  I  — I 


tonntl 
to-f rom- all 
arrow 


-I- 


78  178  | 


to-f row-all 
arrow 


I . 

I  down-arrow 

I . 


I . 

101 

I  right-arrow 

I . . 


I . . 

I  right-down 

I . . 


Idown-right 


I 

I 


I . . 

I  right-up 
I . 


I . 

I  up-right 


| - 

I  down-arrow 
I . 


I hiddwn-souxcw 

It 

I  right-arrow 
I . 


I . . 

14 

I  right-arrow 


I 

I 

I 


■I 

I 

I 

I 


I 

I 

I 


I 

I 

I 


I 


I 

I 

I 


I 

I 

I 


I 

I 

I 


I 

I 

I 

I 

I 


I 

I 

I 

■I 


1(33 


I  —  I  —  I  —  I  —  I 
179  |79  180  180  I 


I  — I - 1 . 1 . 

179  |79  lto-fro*-all  I A 

180  |80  I  arrow  I  right-arrow 


(squiggles) 

111  l]Tl  1x2  I  jr2  1x3  |  jr3  1x4  I  y4  I 


(met  a_not  ••) 

I  label  lx  ly  I 

I . I - 1 - 1 


(note.text) 

I  lina.no  Itaxt.lina  I 

I . I . I 


(foot.notaa) 

I labal  I  xn  I ym  |xn  lyn  I 

I . -I  — I  — I  — I  — I 

I . I  — I  — I  — I  — I 

(nota.taxt) 

llina.no  Itaxt.lina  I 

I . I . I 

I- . I . I 

(faoa) 

I labal  |x  ly  Ipictura  I 

I . I - 1 - 1 . 1 

I . I - 1 - 1 . 1 

( labals) 


1  najB« 

lx 

It 

1 userdata 

117 

117 

1  unumber 

120 

120 

1 ualpha 

122 

122 

1  rules 

125 

125 

1 numberrules 

128 

128 

1 alpharnlos 

130 

130 

1 feedback 

134 

134 

1  nujnbenasgs 

137 

137 

1 alphaasgs 

141 

141 

lfctrl/*13 

155 

155 

1  error  code 

185 

ias 

I - 1 - 1 


I 

I 

I 

I 


F.rtmct  Essential  Data 


The  following  queries  extract  essential  data  from  the  nested-relational  implement  at  ion  « ■!'  i  h 
IDEFo  database.  The  first  query  extracts  the  data  for  a  typical  activity  data  dictionary  1  li 
second  query  extracts  the  data  for  a  typical  data  element  data  dictionary.  As  before,  these  querie 
are  associated  with  the  diagram  shown  in  Figure  8. 


KJ-4 


Activity  Data  Dictionary.  This  next  SQL/NF  query  illustrates  the  extraction  of  the  'lata 
dictionary  data  (essential  data)  associated  with  a  typical  activity  (A1  in  the  example). 


SELECT  (SELECT  ALL  BUT  node, id , c .number , hist. calls .children  FROM  activities  WHERE  node  =  "At") 
FROM  project 

WHERE  project. name  »  "DM  Example"; 

(activities) 

Inode  Iname  lauthor  Iversion  Idate  Ichanges  Iparent  I 

I . I . I . . 1 . -I . . I . -I . I 

IA1  | manage  numeric  data  IGerald  R.  Morris  1 1.0  112/14/89  I  Imanage  database  I 

| - 1 - - | . | . | - 1 - - | . | 

(act.deacr) 

lline.no  Idescr.line  I 

I . I . . 1 

|1  IThis  activity  will  I 

12  I  handle  numbers  I 


(refrences) 

I  ref. type  I 


I  contract  I 

I . I 

(ref.lines) 

lline.no  I  ref. line  I 


|1  I  KIR  100028-89-0123  3.3.2  1.2a  I 

I . I . I 

(data.elems) 

I  data. name  I ieom.type  I 


I  unumber  1 1 
I  errors  II 
Inumberrules  1C 
|  numbermsgs  I  □ 


lt»5 


Data  Element  Data  Dictionary  This  next  SQL/NF  query  illustrates  the  extraction  of  the  .lata 
dictionary  data  (essential  data)  associated  with  a  typical  data  element  (unumlu-r  in  the  examph  i 


SELECT  (SELECT  ALL  BUT  data.id  FROM  data.elements  WHERE  name  *  "unumber") 
FROM  project 

WHERE  project. name  =  "DM  Example"; 

(data. elements) 

{name  1  author  Iversion  Idate  I  changes  I  parent  I 

I . I . — . I - 1— . I - I . I 

I  unumber  IGerald  R.  Morris  1 1.0  102/14/89  I  luserdata  I 

I - - I-- . I . —  I- . 1 . . I . —  I 

(data.descr) 

lline.no  Idescr.line  ! 


11  IThis  is  the  user  numeric  data  I 

I . I - - I 

(refrences) 

I  ref. type  I 


UFM  I 

I . I 

(ref. lines) 

lline.no  I  ref. line  I 


I  . I . - . . I 

II  I  AFM  3S-10  page  3  para.  23  I 

I . I . - . I 

(aliases) 

I  name  lahere.used  I  comment  I 

! . I . I . I 

I . I . I . I 

(min.max) 


Idata.type  Iminimum  Imaximum  I 

I . I . I- . I 


(range) 

Idata.type  I  range 


I  integer  I  integer ’range  I 


, - J - - 

(values ) 

Idata.typa  laalua 

i 

( act ivitaas) 

1 noda_na*a 

I - 

1 icom.type 

Imanage  numeric  data  II  I 


( children) 

Idata.name  I 


I 


hit; 


Appendix  J.  Ada  Package  for  Drawing  Data  Structures 


The  following  (incomplete)  package  specification  illustrates  the  data  struct  tires  that  might  I" 
used  to  capture  the  drawing  data  in  the  IDEFo  database.  Obviously  some  type  of  embedded  qu<M> 
language  capability  would  be  required. 


with  activity.data,  data.element.data,  analyst.data ; 
package  drawing.data  is 

—  This  package  defines  the  data  structures  that  are  used  to  capture  the 
--  drawing  data  from  the  IDEFO  database  via  embedded  query  language  calls 

--  It  is  not  known  apriori  how  many  tuples  there  are,  30  a  linked  list 
--  structure  is  used. 

--  The  element  names  correspond  identically  to  the  attribute  names  used  in 
--  the  IDEFO  database.  It  is  assumed  the  user  of  this  package  is  familiar 
--  with  the  database  schema. . . 

type  box; 

type  box.pointer  is  access  box; 
type  box  is  record 

node  :  activity.data. node. type; 

name  :  activity_data.name_type; 

x  :  integer; 

y  :  integer; 

visible.dre  :  integer; 

next_box  :  box.pointer  .  =»  null;  —  next  box  in  list 

end  record; 


type  loc; 

type  loc.pointer  is  access  loc; 
type  loc  is  record 

xs  :  integer; 

y3  :  integer; 

xe  :  integer; 

ye  :  integer; 

next.loc  :  loc.pointer  :■  null; 

end  record; 


type  symbol; 

type  symbol  .pointer  is  access  symbol; 
type  symbol  is  record 


x 

y 

type. symbol 
symbol.type 
next.symbol 
end  record; 


integer ; 
integer ; 
stringd  .  .  12) ; 
string! 1 . .  12) ; 
symbol. pointer  :■ 


null ; 


--  next  location 


--  next  symbol 


type  seg; 

type  seg.pointer  is  access  3eg; 
type  seg  is  record 

location  :  loc.pointer  :*  null; 
symbols  ;  symbol.po inter  :»  null; 

next.seg  :  seg.pointer  ;»  null;  --  next  segment 

end  record; 


type  squig ; 

type  squig. pointer  is  access  squig; 
type  squig  is  record 


xl 

integer; 

yi 

integer ; 

x2 

integer ; 

y2 

integer; 

x3 

integer; 

y3 

integer; 

x4 

integer; 

y4 

integer; 

next.squig 

squig.pointer  :»  null; 

end  record; 
type  note.txt; 

type  note.txt.po inter  is  access  note.txt; 
type  note.txt  is  record 

line.no  :  integer; 

text.line  :  string! 1 . . 60) ; 

next_note.txt  :  note.txt.pointer  :»  null; 

end  record; 

type  meta; 

type  meta.pointer  is  access  meta; 
type  meta  is  record 

label  :  string(l . . 1) ; 

x  :  integer; 

y  :  integer; 

note.text  :  note.txt.pointer  :»  null; 

next .meta  :  meta.pointer  :»  null; 
end  record; 


—  next  squiggle 


—  next  line  of  text 


—  next  meta-note 


type  foot; 

type  foot.pointer  is  access  foot; 
type  foot  is  record 

label  :  stringO  . .  1)  ; 

xa  :  integer; 

ym  ;  integer; 

xn  :  integer; 

yn  :  integer; 

note.text  :  note.txt.pointer  :»  null; 

next. foot  :  foot.pointer  :»  null;  —  next  foot-note 

end  record; 
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type  feo; 

type  feo.pointer  is  access  feo; 
type  feo  is  record 

label  ;  string( 1 . . 1) ; 

x  :  integer; 

y  :  integer; 

picture  :  string(l . . 60) ; 

next.feo  :  feo.pointer  :«  null;  --  next  FEO 

end  record; 

type  label; 

type  label.pointer  is  access  label; 
type  label  is  record 

name  :  stringCl . .  10) ; 

x  :  integer; 

y  :  integer; 

next.label  :  label.pointer  : *  null;  —  next  label 

end  record; 

type  sheet; 

type  sheet.pointer  is  access  sheet; 
type  sheet  is  record 

c .number  integer; 
node  activity_data.node.type; 

name  activity_data.name.type; 

author  analyst.data. author.type ; 

version  act ivity.data. version.type ; 

date  activity_data.date.type; 

boxes  box.pointer  :»  null; 

segments  seg.pointer  :»  null; 

3<luiggle8  :  squig.pointer  :■  null; 
meta.notes:  meta.pointer  : »  null; 
foot.notes:  foot.pointer  :»  null; 
feoa  feo.pointer  :■  null; 

labels  label.pointer  :•  null; 

end  record; 

procedure  draw_a.O_sheet(the_sheet  :  in  sheet.pointer); 

--  and  some  other  stuff  as  well 
end  drawing.data; 
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Abstract : 


This  thesis  develops  an  abstract  data  model  of  a  particular  computer 
aided  software  engineering  (CASE)  methodology,  and  compares  the  query 
complexity,  database  size,  and  speed  oi  query  execution  of  a  relational 
database  management  system  (DBMS)  implementation  of  the  methodology 
with  a  nested-relational  DBMS  implementation  of  the  same  CASE  methodology. 
In  particular,  the  thesis  considers  the  United  States  Air  Force  Integrated 
Computer  Aided  Manufacturing  (ICAM)  program’s  subset  of  Ross’s  Structured 
Analysis  (SA)  language  called  ICAM  Definition  Method  Zero  (IDEF0). 

Ingres  Corporation’s  relational  DBMS,  Ingres,  is  the  implementation 
media  fcr  the  relational  version.  The  University  of  Wisconsin’s  extensible 
database,  Exodus,  is  the  implementation  media  for  the- nested-relational 
version. 

The  thesis  provides  background  information  on  the  development  of 
CASE  methodologies  and  the  development  of  database  management  systems. 
Additionally,  it  provides  an  overview  of  the  IDEFo  analysis  language, 
and  the  Exodus  extensible  DBMS. 

Inc_uded  in  the  thesis  is  an  abstract  data  model  of  the  IDEFo  language. 
The  model  partitions  IDEFo  into  an  essential  data  model  and  a  drawing 
data  model.  This  partitioned  representation  facilitates  ongoing  and 
future  research  relative  to  syntax  checking,  generation  of  an  executable 
software  specification,  and  automatic  layout  of  SA  diagrams.  Since 
IDEFo  is  the  analysis  methodology  selected  by  the  Strategic  Defense 
Initiative  Organization,  the  abstract  data  model  alone  is  of  importance. 

The  abstract  data  model  is  mapped  into  a  relational  representation 
and  implemented  within  Ingres.  The  relational  representation  is  mapped 
into  a  nested-relational  representation  and  implemented  within  Exodus. 

The  two  implementations  are  compared  to  see  if  there  are  any  advantages 
to  be  gained  by  using  a  nested-relational  DBMS  for  this  type  of  application 
(CASE  tool  data).  The  areas  of  comparison  include  query  complexity, 
size  the  database,  and  speed  of  query  execution. 


